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APPEAL BRIEF 

Mail Stop Appeal Brief - Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

Pursuant to the Notice of Appeal mailed June 9, 2004 in connection with the 
above-identified patent application, the applicant respectfully submits the instant Brief 
on Appeal in accordance with 37 C.F.R. § 1.192. Enclosed is a check in the amount 
of $340.00, pursuant to 37 C.F.R. § 1.17(c). If there are any additional fees or refunds 
required, the Commissioner is directed to charge or debit Deposit Account No. 13- 
2855. 



I. REAL PARTY IN INTEREST 

The real party in interest is Motorola, Inc. the assignee of the above-identified 

patent application. The assignment assigning rights to Motorola, Inc., is recorded in 
the United States Patent and Trademark Office ("USPTO") at Frame 012537 of Reel 



0727. 

10/15/2004 NBEYENE1 00000029 09943888 

01 FCsl402 0P 



Serial No. 09/943,882 Atty. Docket No. IA00006 

Appeal Brief dated October 12, 2004 

Appeal from the Final Action dated FEB. 10, 2004 

II. RELATED APPEALS AND INTERFERENCES 

There are no related interferences. 

An appeal against the rejection of the each of the following related patent 
applications has been filed: 

Serial number 09/943,921 entitled VEHICLE ACTIVE NETWORK WITH 
BACKBONE STRUCTURE; 

Serial number 09/944,892 entitled VEHICLE ACTIVE NETWORK WITH 
RESERVED PORTIONS 

Serial number 09/944,893 entitled VEHICLE ACTIVE NETWORK WITH 
DATA ENCRYPTION. 

III. STATUS OF THE CLAIMS 

Currently, claims 1-5 and 7-17 are pending in the application. The pending 

claims are presented in Appendix A to this Brief. Claims 1-5 and 7-17 stand rejected 
and form the subject matter of this appeal. 

The application was filed on August 31, 2001, with claims 1-17. 

A preliminary amendment filed on August 31, 2001 made minor changes to 
the specification to include reference to related applications. 

The first Office action mailed June 24, 2003, inter alia, rejected claims 1-17 
under 35 U.S.C. § 102(b) as anticipated by Ying (U.S. Patent No. 6,094,416). The 
examiner alleged that the dots in figure 5 of Ying (element 642 in figure 6) for 
connecting the devices to the buses are considered the claimed active network 
elements. 

The applicants responded to the Office action on August 4, 2003. the 
applicants argued that Ying fails to disclose or suggest the claimed invention. In 
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particular, Ying does not disclose or even suggest a vehicle comprising a first device, 
a second device and an active network communicatively coupling first and second 
device. Furthermore, Ying discloses a common bus network and does not disclose or 
teach an active network, which is fundamentally different from the bus-type network 
and bus controller disclosed by Ying. An active network is a network in which the 
nodes (active elements) are programmed to perform custom operations on the 
messages that pass through the node; thus active elements within an active network 
enable multiple simultaneous communication paths between devices within the 
network (page 7, lines 6-7 of Applicant's specification). This is in stark contrast to the 
bus-type network disclosed by Ying, in which there are no simultaneous 
communication paths between devices. An active network does not use a bus-type 
architecture or a central computing resource such as a bus controller (i.e. a network 
utility or arbiter as described on page 6, lines 4-6 of Applicant's specification). 

The examiner issued a second non-final Office action on October 22, 2003, 
rejecting claims 3, 4, 6-8 under U.S.C. 1 12, second paragraph, as being indefinite, 
rejecting claims 1-4 and 7-16 under 35 U.S.C. § 102(e) as being anticipated by Staiger 
(U.S. Patent No. 6,292,718), and rejecting claims 5, 6 and 17 under 35 U.S.C. § 
103(a) as being unpatentable over Staiger. In particular, the examiner stated that 
Staiger discloses in figure 3 an active network used in a vehicle comprising a first 
device (control element 'SysMon'), a second device (control element 'CAP 1 ), first 
communication coupling for connecting the first device to the network, and a second 
communication coupling for connecting the second device to the network. 

The applicants responded to the Office action on December 8, 2003. The 
response amended claims 3, 4, 7 and 8 and cancelled claim 6. The amendments to 
claims 3, 4, 7 and 8 were made with the only aim of improving the clarity of the 
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claims. The applicants argued that Staiger fails to disclose or suggest the claimed 
invention. In particular, Staiger teaches an electronic control system for controlling 
the function of a processing system in an automobile and using operating systems 
such as OSEK or QNX, which do not support an active network (column 8, lines 27- 
30). Also Staiger supports communication paths that employ preferably interrupt 
driven solutions, polling techniques, multi-drop networks, arbitration and 
decentralized bus schemes (Fig. 2 and column 11, lines 24-45); none of these is an 
active network or support active network functions. Staiger clearly requires a central 
management unit to control other nodes in the system (Figures 1-7) and a central 
management unit is at the center of a passive network. The various units in Staiger 
cannot perform custom operation on messages passing through them. In addition 
various units in Staiger are not aware of, and cannot participate in the processing or 
modification of, the contents of messages passing through them. Therefore, nowhere 
does Staiger teach or suggest an active network as understood by those skilled in the 
art. In support of these statements, the applicants provided an Affidavit under 37 CFR 
1 .132 affirming by one of the inventors, who is also an expert in the field of 
computing and networking, that a active network is a network in which the nodes can 
perform custom operations on the contents of the messages that pass through the 
nodes, an active network does not require a central server or computing resource, 
active network nodes are aware of the content of the messages transported and can 
participate in the processing and modification of the messages while they travel 
through the network. 

The examiner issued a final Office action on February 10, 2004, rejecting 
claims 1-4 and 7-16 under 35 U.S.C. § 102(e) as being anticipated by Staiger, and 
rejecting claims 5 and 17 under 35 U.S.C. § 103(a) as being unpatentable over 
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Staiger. The examiner states that the features upon which applicant relies and relating 
to an active network are not recited in the rejected claims. Although the claims are 
interpreted in light of the specification, limitations from the specification are not read 
into the claims. Furthermore, nowhere does the specification provide a clear definition 
of the claimed "active network" or limits what an "active network" can perform. 
Although it may be true that an "active network" can be interpreted as a network that 
performs the functions as argued in the Remarks and stated in the Affidavit, such an 
interpretation is not the only possible interpretation. As such, the claims are given the 
broadest reasonable interpretation consistent with the specification for the purpose of 
examination. In this instance, Staiger discloses a system in figure 3 for supporting 
multiple types of communication task comprising controlling, testing... (column 10, 
lines 34-42); therefore the network of figure 3 is an active network. 

The applicants response to the final Office action filed on May 10, 2004 
contained no new amendments. The applicants maintained that Staiger failed to 
disclose or suggest the claimed invention including, inter alia, an active network. In 
determining whether the claims meet the requirements of patentability including § 
102(e) and 103(a), the applicants 1 disclosure is properly relied upon to determine the 
meaning of terms used in the claims. While doing so, the perspective of the person of 
ordinary skill in the art must be considered, particularly with respect to claimed 
elements that are well know. In such cases, it is not necessary for the applicants to 
describe those elements in detail, and the element should be considered to include all 
art-recognized hardware or combinations of hardware and software techniques for 
implementing that element. Furthermore, it is appropriate to give claims their 
broadest reasonable interpretation in light of the supporting disclosure. With the 
requirements for patentability in mind, the applicants claim vehicles and methods 



Serial No. 09/943,882 Atty. Docket No. IA00006 

Appeal Brief dated October 1 2, 2004 

Appeal from the Final Action dated FEB. 10, 2004 

implemented within a vehicle comprising active networks. The applicants have 
claimed a specific physical structure, namely an active network known to have 
particular characteristics, within a vehicle. This active network is not a bus 
architecture and is not a passive network or a combination of a passive network and a 
bus architecture or any other type of network structure than an active network 
structure. In light of the specification, the broadest reasonable interpretation of the 
term active network does not include bus structures and/or passive networks. 

The examiner issued an advisory action on June 9, 2004. The advisory action 
stated that the request for reconsideration has been considered but does not place the 
application in condition for allowance because the applicant arguments are not 
persuasive: As such, claims 1-5 and 7-17 are rejected. 

IV. SUMMARY OF THE INVENTION 

Although specification citations are inserted below in accordance with C.F.R. 

1.192(c), these reference numerals and citations are merely examples of where 
support may be found in the specification for the terms used in this section of the 
brief. There is no intention to in any way suggest that the terms of the claims are 
limited to the examples in the specification. Although, as demonstrated by the 
reference numerals and citations below, the claims are fully supported by the 
specification as required by law, it is improper under the law to read limitations from 
the specification into the claims. Pointing out specification support for the claim 
terminology, as is done here to comply with rule 1.192(c), does not in any way limit 
the scope of the claims to those examples from which they find support. Nor does 
this exercise provide a mechanism for circumventing the law precluding reading 
limitations into the claims from the specification. In short, the reference numerals and 
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specification citations are not to be construed as claim limitations or in any way used 
to limit the scope of the claims. 

The invention, as defined in claims 1 and 10, and with reference to FIGS. 1-4 
and 10, is a vehicle 10 including a first device, e.g., 136, and second device, e.g., 14, 
16, 18 or 20 and an active network 30 communicatively coupling the first device 136 
and the second device 16. At least a first communication link 140, 142 or 144 and a 
second communication link 140, 142 or 144 communicatively couple the first device 
to the active network 30. The device 136 may include an active network element 
formed integral with the device. A plurality of input/output ports communicatively 
couple the device 136 via the communication links 140, 142 or 144 to the active 
network 30. Data streams may be communicated along each of the communication 
paths 140, 142 and 144 to a destination device coupled to the active network 30. 

As depicted in FIG. 11, the device 136 maybe network sub-system 152 
including a plurality of devices 154, 156 or 158. The sub-system 152 incorporates an 
active network element 166 that is coupled to the active network 30. Still in further 
alternative, the device 136 may be redundant elements, whether devices or active 
network elements 172 and 174, FIG. 12. 

V. ISSUES ON APPEAL 

The issue presented on appeal is: are each of pending claims 1-5 and 7-17 

patentable over Staiger, U.S. Patent No. 6,292,71 8? 

VI. ARGUMENT 

In the final Office action dated February 10, 2004, the examiner states "Staiger 

discloses in figure 3 a network for supporting multiple types, of communication task 
comprising controlling, testing. . .; therefore the network of figure 3 is an active 
network". In other words, the Examiner considers appropriate to give to the term 
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"active network" the broadest possible interpretation by considering the word "active" 
as a simple adjective to the word "network"; in this light, an "active network" is a 
network capable of doing any kind of action. Following the interpretation of the 
examiner, every network is an active network, due to the fact that it is at least able of 
establishing a connection. Due to the fact that it is impossible to claim a network 
which is not active with the meaning given by the examiner (a non-active network, 
according to the examiner, is a network which does not do anything, and thus it is a 
completely unuseful network), according to the examiner the word "active" does not 
confer any kind of limitation to the word "network". 

Furthermore, the examiner states that "The features upon which applicant 
relies and relating to an active network are not recited in the rejected claims. Although 
the claims are interpreted in light of the specification, limitations from the 
specification are not read into the claims. Furthermore, nowhere the specification 
provides a clear definition of the claimed "active network" or limits what an "active 
network" can perform. Although it may be true that an "active network" can be 
interpreted as a network that performs the functions as argued in the Remarks and 
stated in the Affidavit, such an interpretation is not the only possible interpretation." 

Is the above interpretation of the word "active" given by the examiner correct 
and conform to the U.S. patent practice established by the Manual of Patent 
Examining Procedure ? 

According to MPEP § 2 1 1 1 .01 : 

"during examination the pending claims must be given their broadest 
reasonable interpretation consistent with the specification" 
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"the broadest reasonable interpretation of the claims must also be consistent 
with the interpretation that those skilled in the art would reach" 

"When not defined by applicant in the specification, the words of a claim must 
be given their plain meaning. In other words, they must be read as they would be 
interpreted by those of ordinary skill in the art." 

"During the examination the pending claims must be interpreted as broadly as 
their terms reasonably allow. This means that the words of the claims must be given 
their plain meaning unless applicant has provided a clear definition in specification." 

"Especially in non-chemical cases, the words in a claim are generally non 
limited in their meaning by what is shown or disclosed in the specification, It is only 
when the specification provides definitions for terms appearing in the claims that the 
specification can be used in interpreting claim language." 

In the specification the applicant does not give a clear definition of an active 
network (as recognized by the examiner the final office action) and also does not 
teach all the instructions for realizing an active network. The reason is simple: those 
of ordinary skill in the art know perfectly what an active network is, what an active 
network does and how to realize an active network. This is not an arbitrary 
assumption made by the attorney, but is based on the Affidavit under 37 CFR 1.132 
made by Juergen Reinold one of the inventors who is also an expert in the field of 
computing and networking, copy attached in Appendix B. Attached also is further 
evidence of what one of ordinary skill in the art would understand an active network 
to be in the Appendices C, D and E which include technical references and articles, 
written by third parties with no link to the present patent application. These 
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additional references and articles demonstrate that an active network is a name used 
for recognizing a very particular kind of network. 

According to the aforementioned part of the MPEP: 

"When not defined by applicant in the specification, the words of a claim must 
be given their plain meaning. In other words, they must be read as they would be 
interpreted by those of ordinary skill in the art " 

Owing to the fact that applicant does not provide a special definition of the 
term "active network", such term must be given its plain meaning, i.e. it must be read 
as it would be interpreted by those of ordinary skill in the art. In any case, the 
broadest reasonable interpretation must to consistent with the specification and must 
also be consistent with the interpretation that those skilled in the art would reach. The 
interpretation of the term "active network" given by those of ordinary skill in the art is 
clear (see the aforementioned Affidavit and attached references): "inter alia, an active 
network is a network including nodes capable of performing custom operations on the 
messages that pass through the nodes 11 . Such interpretation is also consistent with the 
specification, which does not define what an active network is, but well define what 
an active network is not (i.e. an active network is not a BUS network of the type 
disclosed by Staiger). 

To give to the term "active network" the aforementioned meaning associated 
by the examiner, an "active network" is a network capable of doing something, it is 
clear that the term "active network" has a meaning that is not consistent with the 
interpretation that those skilled in the art would reach (see the aforementioned 
Affidavit and references). Furthermore, the term "active network" is given a meaning 
that is not consistent with the specification: according to this meaning, e.g., a BUS 
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network is an active network, but in the specification it is clearly stated that a BUS 
network is not an active network. Both such considerations demonstrate without any 
doubt that this interpretation does not conform with the teaching of the MPEP and 
thus it is not appropriate. 

Claim 1 positively recites an active network, which is a specific physical 
structure known to have particular characteristics, within a vehicle. This active 
network is not a bus architecture and is not a passive network or a combination of a 
passive network and a bus architecture or any other type of network structure than an 
active network structure. Staiger does not disclose any active network and thus claims 
1 or 10 cannot be anticipated by Staiger. To establish a prima facie case of 
obviousness, and hence to find claims 1 or 10 unpatentable under 35 U.S.C. § 103(a) 
and over Staiger, three basic criteria must be met. First, there must be some 
suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable expectation of 
success. Finally, the prior art reference (or references when combined) must teach or 
suggest all of the claim limitations. The teaching or suggestion to make the claimed 
combination and the reasonable expectation of success must both be found in the prior 
art, and not be based upon applicant's disclosure. MPEP at § 2142. In the present 
case, Staiger fails to teach or even suggest the use of an active network within a 
vehicle. Thus claim 1 is not obvious in view of Staiger. 

In determining whether the claims meet the requirements of patentability 
including § 102(e) and 103(a), the applicants' disclosure is properly relied upon to 
determine the meaning of terms used in the claims . While doing so, the perspective 
of the person of ordinary skill in the art must be considered, particularly with respect 
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to claimed elements that are well know. In such cases, it is not necessary for the 
applicants to describe those elements in detail, and the element should be considered 
to include all art-recognized hardware or combination of hardware and software 
techniques for implementing that element. Furthermore, it is appropriate to give 
claims their broadest reasonable interpretation in light of the supporting disclosure . In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997) 
(emphasis added). Limitations appearing in the specification but not recited in the 
claim are not read into the claim. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 
541, 550-551 (CCPA 1969). See also In re Zletz, 893 F.2d 319, 321-22, 13 USPQ2d 
1320, 1322 (Fed. Cir. 1989) ("During patent examination the pending claims must be 
interpreted as broadly as their terms reasonably allow .... The reason is simply that 
during patent prosecution when claims can be amended, ambiguities should be 
recognized, scope and breadth of language explored, and clarification imposed.... An 
essential purpose of patent examination is to fashion claims that are precise, clear, 
correct, and unambiguous. Only in this way can uncertainties of claim scope be 
removed, as much as possible, during the administrative process."). See MPEP at § 
2106. 

The issue of patentability under § 103 raised by the Office action, and 
which the applicant must overcome, is whether Staiger renders unpatentable claims 5 
and 17 under 35 U.S.C. § 103(a). 

The applicants claim vehicles and methods implemented within a 
vehicle comprising active networks. The applicants assert, supported by the 
aforementioned Declaration and references, that an active network is known to the 
skilled artisan to include, inter alia nodes capable of performing custom operations on 
the messages that pass through the nodes. An active network does not require a 

- 12- 
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central server or computing resources. And, active network nodes are aware of the 
contents of messages transported and can participate in the processing and 
modification of the messages while they travel through the network. That is, an active 
network is a defined physical structure that is unlike other communication structures 
such as communication busses and/or passive networks. Moreover, the applicants 
clearly distinguish particular kinds of passive networks, such as bus architectures, in 
the background portion of the specification. Beginning at page 2, line 3 of the 
specification, the applicants explain that, in accordance with existing design 
philosophy, various communication bus structures for interconnecting control 
elements, sensors, actuators and like structures within vehicle have been used, but that 
these architectures. suffer a number limitations. The applicants further explain, 
beginning at page 2, line 19 of the specification, that network structures have been 
incorporated in connection with bus architectures. These passive network structures 
do not provide sufficient reliability for vehicle functional requirements such as power 
train, suspension, airbag systems, and the like, and usage has been limited to 
applications wherein information technologies are added to the vehicle. Thus, as the 
applicants have explained, existing architectures have not met the needs of efficient, 
reliable integration of in- vehicle electronic technologies and plug-and-play 
upgradeability. 

Clear from the foregoing discussion, the applicants have claimed a 
specific physical structure, namely an active network known to have particular 
characteristics, within a vehicle. This active network is not a bus architecture and is 
not a passive network or a combination of a passive network and a bus architecture or 
any other type of network structure than an active network structure. In light of the 
specification, the broadest reasonable interpretation of the term active network does 
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not include bus structures and/or passive networks. For the claims to be anticipated or 
unpatentable, i.e., not to meet the requirements of § 102(e) or § 103(a), the prior art 
must teach or suggest each and every limitation contained in the claims, and 
particularly, in this case, must teach or suggest a vehicle including an active network. 
Because the prior art fails to teach or suggest this structure or methods employing 
such structures, claims 1-5 and 7-17 do meet the requirements of 35 U.S.C. § 102(e) 
and 35 U.S.C. § 103(a) and are patentable. 

The Office action essentially admits that, unless the claims are read 
more broadly than the ordinary meaning of the term "active network" and the 
specification permits, the claimed vehicle and active network combination is not 
taught or suggested by the art and particularly by Staiger. Moreover, the applicants 
have pointed in the Reinold Declaration to the numerous arid significant deficiencies 
of Staiger as a reference against the instant application and particularly as it relates to 
failing to describe active networks. It is only under what the applicants submit is an 
unreasonably broad interpretation of the term "active network," one not supported by 
what is known to the skilled artisan and the specification in that an active network is a 
known physical structure and that in addition the specification clearly describes what 
an active network is not, that the claims can be found to be unpatentable. 

It is asserted that the applicants are arguing limitations not contained in 
the claims. The applicants submit the limitations they argue, the physical structure 
and function of the active network, are subsumed by the term itself. It is no more 
necessary to amend the claims to recite the physical structure of the active network to 
establish patentability, a known thing, than it would be necessary to recite an engine, 
transmission, chassis, wheels, seats, etc. of the claimed vehicle in order that it be 
understood. Doing so is redundant. This simply is not an instance where the 

- 14- 
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applicants are arguing structures contained in the specification but not in the claims, 
but instead the applicants are arguing the structures defined by the term active 
network. 

VII. CONCLUSION 

In view of the foregoing remarks, it is respectfully submitted that each of the 

rejections of claims 1-5 and 7-17 is patentable over the prior art, and that all of the 
pending claims should be allowed. 

Respectfully submitted, 



^October .12,- 2004 By: 




"Anthony G. Sitko 
Attorney for Applicant & Assignee 
Registration No. 36,278 
Marshall, Gerstein & Borun LLP 
233 South Wacker Drive . 
6300 Sears Tower 
Chicago, Illinois 60606-6357 
Tel.: (312) 474-6300 
Fax: (312) 474-0448 
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APPENDIX A 
Claims 

1 . (original) In a vehicle comprising a first device and a second device and an 
active network communicatively coupling the first device and the second device, the 
first device having a first communication coupling to the active network and a second 
communication coupling to the active network. 

2. (original) The vehicle of claim 1, wherein the active network comprises a 
plurality of active network elements coupled by connection media and wherein the 
first communication coupling couples to a first active network element and the second 
communication coupling couples to a second active network element. 

3. (previously amended) The vehicle of claim 1, wherein the device comprises 
a device active network element, and wherein the first communication coupling and 
the second communication coupling each couple to the device active network 
element. 

4. (previously amended) The vehicle of claim 1, wherein the device comprises 
a first device active network element and a second device active network element, and 
wherein the first communication coupling couples to the first device active network 
element and the second communication coupling couples to the second device active 
network element. 



- 16- 



SerialNO. 09/943,882 ATTY. DOCKET No. IA00006 

Appeal Brief dated October 1 2, 2004 

Appeal from the Final Action dated FEB. 10, 2004 

5. (original) The vehicle of claim 4, wherein the first device active network 
element and the second device active network element are communicatively coupled 
by connection media. 

6. (canceled) 

7. (previously amended) The vehicle of claim 1, wherein the first device 
comprises a first device active network element and a second device active network 
element, and wherein the first communication coupling and the second 
communication coupling each couples to the first device active network element and 
the second device active network element. 

8. (previously amended) The vehicle of claim 1, wherein the first device has a 
first device element coupled to the first coupling and a second device element coupled 
to the second coupling. 

9. (original) The vehicle of claim 1, wherein active network comprises a 
packet data network. 

10. (original) In a vehicle comprising an active network for communications 
within the vehicle, a method of coupling a device to the active network comprising: 

providing a first communication coupling from the device to the active 
network at a first location on the active network; and 

providing a second communication coupling from the device to the active 
network at a second location on the active network. 
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11. (original) The method of claim 10, wherein the active network comprises a 
plurality of active network elements coupled by connection media, and wherein the 
step of providing a first communication coupling comprises coupling the device to a 
first active network element of the plurality of active network elements and the step of 
providing a second communication coupling comprises coupling the device to a 
second active network element of the plurality of active network elements. 

12. (original) The method of claim 10, wherein the active network comprises a 
plurality of active network elements coupled by connection media, and wherein the 
step of providing a first communication coupling comprises coupling the device to an 
active network element of the plurality of active network elements and the step of 
providing a second communication coupling comprises coupling the device to the 
active network element. 

13. (original) The method of claim 10, wherein the active network comprises a 
plurality of active network elements coupled by connection media and the device 
comprises a device active network element, and wherein the step of providing a first 
communication coupling comprises coupling the device active network element to a 
first active network element of the plurality of active network elements and the step of 
providing a second communication coupling comprises coupling the device active 
network element to a second active network element of the plurality of active network 
elements. 
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14. (original) The method of claim 10, wherein the active network comprises a 
plurality of active network elements coupled by connection media and the device 
comprises a first device active network element and a second device active network 
element, and wherein the step of providing a first communication coupling comprises 
coupling the first device active network element to a first active network element of 
the plurality of active network elements and the step of providing a second 
communication coupling comprises coupling the second device active network 
element to a second active network element of the plurality of active network 
elements. 

■ 15. (original) The method of claim 10, wherein the active network comprises a 
plurality of active network elements coupled by connection media and the device 
comprises a first device active network element and a second device active network 
element, and wherein the step of providing a first communication coupling comprises 
coupling the first device active network element and the second device active network 
element to a first active network element of the plurality of active network elements 
and the step of providing a second communication coupling comprises coupling the 
first device active network element and the second device active network element to a 
second active network element of the plurality of active network elements. 

16. (original) The method of claim 10, wherein the active network comprises a 
plurality of active network elements coupled by connection media and the device 
comprises a first device active network element and a second device active network 
element, and wherein the step of providing a first communication coupling comprises 
coupling the first device active network element and the second device active network 
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element to an active network element of the plurality of active network elements and 
the step of providing a second communication coupling comprises coupling the first 
device active network element and the second device active network element to the 
active network element. 

17. (original) The method of claim 16, wherein the steps of providing a first 
communication coupling and a second communication coupling comprises coupling 
the first device active network element to the second device active network element. 
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I received a Vordiplom in Informatik (analogous to Bachelor of Science Degree in 
Computer Science) from the Rheinisch-Westfahlische Technische Hochschule (RWTH) 
Aachen in Germany in 1985 and the Informatik Diplom (analogous to Master of Science 
Degree in Computer Science) the Rheinisch-Westfahlische Technische Hochschule (RWTH) 
Aachen in Germany in 1989. 

I have been employed by Motorola, Inc. since 1989 where I have served in various 
management and technical capacities. I spent most of my technical work at the Motorola 
Computer Group, both in Dusseldorf/Germany and in Tempe/Arizona. I have developed 
system software, performed system and performance analysis on complex computing and 
communication systems, and created the architecture for the StarMax Pro 6000 desktop 
computer, "The Fastest Personal Computer On Earth" according to MacWeek Magazine in 
August 1997. 1 led a team of engineers as the Chief Architect on a development effort in 
Motorola geared towards the next generation systems architecture for automotive electronic 
systems. I have published several papers and given key note speeches on computer system 
performance and architecture issues. Additionally, I have inventively contributed to more 
than thirty filed or issued US patents for Motorola. 

I, Juergen Reinold, am an inventor of the above referenced patent application and 
have reviewed U.S. Patent No. 6,292,718 (hereinafter Staiger) and state the following: 

The present invention teaches a vehicle comprising an active network. Staiger does 
not disclose or suggest a vehicle comprising an active network. Moreover, even if the subject 
matter of Staiger were combined with other art of record, this would not lead anyone to 
develop the invention. For example, Staiger in combination with other art of record does not 
teach all of the claimed features namely, a vehicle comprising an active network. See, for 
example, independent claims 1 and 10 of the application. 

As is known in the art, traditional data networks (passive networks) passively 
transport messages from one end node to another. Such passive networks are only aware of 
the destination of messages passing through the nodes and are specifically designed to deliver 
exactly one unmodified copy of the message to its ultimate destination. The passive network 
is insensitive to the messages it carries and the messages are transferred between nodes 
without modification. This is exclusively the type of network taught in Staiger. 
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As understood by those skilled in the art of computing and networking, an active 
network is a network in which the nodes can perform custom operations on the contents of 
the messages that pass through the nodes. An active network does not require a central server 
or computing resource. Active network nodes are aware of the contents of the messages 
transported and can participate in the processing and modification of the messages while they 
travel through the network. 

Staiger teaches an electronic control system for controlling the function of a 
processing system in an automobile. The system taught by Staiger uses operating systems 
such as OSEK or QNX, which do not support an active network (column 8* lines 27-30). 
Also, Staiger supports communication paths that employ preferably interrupt driven 
solutions, polling techniques, multi-drop networks, arbitration and decentralized bus schemes 
(FIG.2, and column 1 1 , lines 24-45). None of these is an active network as understood by 
those skilled in the art. In all of these, Staiger clearly requires a central management unit to 
control other nodes in the system (Figures 1-7). Central management unit is at the center of a 
passive network. The various units in Staiger (ComPro, SysMon, CAP, etc.) cannot perform 
custom operations on messages passing through them. In addition various units in Staiger 
(ComPro, SysMon, CAP, etc.) are not aware of, and cannot participate in the processing or 
modification of, the contents of messages passing through them. Therefore, nowhere does 
Staiger teach or suggest an active network as understood by those skilled in the art. 

Staiger fails to teach a vehicle comprising an active network. Consequently, even if 
Staiger were combined with any other reference of record, such a combination would not lead 
to the practice of the invention. See, for example, independent claims 1 and 10 of the 
application. 

I hereby declare that all statements made herein of my own knowledge are true and 
that all statements made on information and belief are believed to be true. I further declare 
that these statements are made with the knowledge that willful false statements and the like 
so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of 
the United States Code and that such willful and false statements may jeopardize the validity 
of the subject patent application or any patent issued thereon. 
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ABSTRACT 

Active networks allow their users to inject 
customized programs into the nodes of the network An 
extreme case, in which we are most interested, replaces 
packets with "capsules " - program fragments that are 
executed at each network router/switch they traverse. 

Active architectures permit a massive increase in the 
sophistication of the computation that is performed 
within the network. They will enable new applications, 
especially those based on application-specific multicast, 
information fusion, and other services that leverage 
network-based computation and storage. Furthermore, 
they will accelerate the pace of innovation by 
decoupling network services from the underlying 
hardware and allowing new services to be loaded . into 
the infrastructure on demand. 

In this paper, we describe our vision of an active 
network architecture, outline our approach to its design, 
and survey the technologies that can be brought to bear 
on its implementation. We propose that the research 
community mount a joint effort to develop and deploy a 
wide area ActiveNet. 

1. INTRODUCTION 

Traditional data networks passively transport bits 
from one end system to another. Ideally, the user data 
is transferred opaquely, i.e., the network is insensitive 
to the bits it carries and they are transferred between 
end systems without modification. The role of 
computation within such networks is extremely limited, 
e.g., header processing in packet-switched networks 
and signaling in connection-oriented networks. 

Active Networks break with tradition by allowing 
the network to perform customized computations on the 
user data. For example, a user of an active network 
could send a customized compression program to a 
node within the network (e.g., a router) and request that 
the node execute that program when processing their 
packets. These networks are "active" in two ways: 

* Switches perform computations on the user data 
flowing through them. 

• Individuals can inject programs into the network, 
thereby tailoring tie node processing to be user- 
and application-specific. 

We have identified several architectural approaches 
to active networks. One approach, which we find 



particularly interesting, replaces the passive packets of 
present day architectures with active "capsules" - 
miniature programs that are executed at each router 
they traverse. This change in architectural perspective, 
from passive packets to active capsules, 
simultaneously addresses both of the "active" 
properties described above. , User data can be 
embedded within these mini-programs, in much the 
way a page's contents are embedded within a fragment 
of PostScript code. Furthermore, capsules can invoke 
pre-defined program methods .or plant new ones within 
network nodes. 

Our work is motivated by both technology "push" 
and user "pull". The technology "push" is the 
emergence of "active" technologies, compiled and 
interpreted, supporting the encapsulation, transfer, 
interposition, and safe and efficient execution of 
program fragments. Today, active technologies are 
applied within individual end systems and above the 
end-to-end network layer; for example, to allow Web 
servers and clients to exchange program fragments. 
Our innovation is to leverage and extend these 
technologies for use within the network - in ways that 
will fundamentally change today's model of what is 
"in" the network. 

The "pull" comes from the ad hoc collection of 
firewalls, Web proxies, multicast routers, mobile 
proxies, video gateways, etc. that perform user-driven 
computation at nodes "within" the network. Despite 
architectural injunctions against them, these nodes are 
flourishing, suggesting user and management demand 
for their services. We are developing the architectural 
support and common programming platforms to support 
the diversity and dynamic deployment requirements of 
these "interposed" services. Our goal is to replace the 
numerous ad hoc approaches to their implementation" 
with a generic capability that allows users to program 
their networks. 

There are three principal advantages to basing the 
network architecture on the exchange of active 
programs, rather than passive packets: 

• Exchanging code provides a basis for adaptive 
protocols, enabling richer interactions than the 
exchange of fixed data formats. 

• Capsules provide a means of implementing fine 
grained application-specific functions at 
strategic points within the network. 



*{dlt,djw}@lcs.mit.edu. http://www.tns.lcs.mit.edu/. An earlier version of this paper was delivered during the 
keynote session of Multimedia Computing and Networking, San Jose, CA, January 1996. 



• The programming abstraction provides a 
powerful platform for user-driven customization 
of the infrastructure, allowing new services to be 
deployed at a faster pace than can be sustained 
by vendor driven standardization processes. 

This paper presents our vision of an active network 
architecture and the approach we are following towards 
the deployment of an operational ActiveNet. The 
active network approach opens a Pandora's box of 
safety, security, and resource allocation issues. 
Although we do not present a complete design, we 
identify a number of specific research issues, outline 
the approach we are following towards their resolution 
and identify the technologies we intend to leverage. 
Our plan is to bootstrap a wide area ActiveNet using 
similar techniques to those used by the prototype 
MBONE, i.e., by locating platforms at strategic 
locations and "tunneling" through existing transmission 
facilities, such as the Internet. 

In the next section we provide a description of some 
of the "lead user" applications that motivate an 
architecture that facilitates computation within the 
network. In section 3, we provide an overview of 
active networks, a high-level perspective on how we 
propose to organize their platforms and an introduction 
to the research issues that must be addressed. Section 
4 describes the "instruction set" issues associated with 
an interoperable programming model and how "active 
technologies" can be leveraged to effect the safe and 
efficient evaluation of capsules. We then discuss the 
management of node resources, such as storage and 
link bandwidth, followed by our plan for the 
deployment of a research ActiveNet. We realize that 
our work challenges some key assumptions that have 
guided recent networking research and so the final 
sections of this paper discuss the architectural and 
structural questions raised by our approach. 

2. LEAD USERS 

Recently, there has been considerable interest in: 
agent technologies, which allow mobile code to travel 
from clients to servers; and in Web applets, which 
allow mobile code to travel from servers to clients. 
Active networks bridge this dichotomy by allowing 
applications to dispatch computation to where it is 
needed. 

We are encouraged by the observation that a 
number of lead users have pressing requirements for the 
transparent interposition of computation within the 
network. These include the developers of: 

• Firewalls, which are typically located at 
administrative boundaries. 

• Web proxies and other services, such as DNS 
and multicast routers, that form strategic vertices 
of copy, fusion and cache "trees". 

• Mobile/Nomadic gateways, placed near the 
edges of the network where there are significant 



discontinuities in the available bandwidth, e.g., 
the base stations of wireless networks. 

These lead applications demonstrate that there is 
user "pull" towards active networks. In the absence of 
a coherent approach to interposition they have adopted 
a variety of ad hoc strategies. In many cases the 
interposed platforms present the facade of network 
layer routers, but actually perform application- or user- 
specific functions. Active networks will rationalize 
these diverse activities by providing a uniform platform 
for network-based computation. 

Firewalls 

Firewalls implement filters that determine which 
packets should be passed transparently and which 
should be blocked. Although they have a peer 
relationship to other routers, they implement 
application- and user- specific functions, in addition to 
packet routing. The need to update the firewall to 
enable the use of new applications is an impediment to 
their adoption. In an Active Network, this process 
could be automated by allowing applications from 
approved vendors to authenticate themselves to the 
firewall and inject the appropriate modules into it. 

Web Proxies 

Web proxies are an example of an application- 
specific service that is tailored to the serving and 
caching of World Wide Web pages. Harvest [1] 
employs a hierarchical scheme in which cache nodes 
are located near the edges of the network, i.e., within 
the end user organizations. This system is scalable and 
could be extended by allowing nodes of the hierarchy 
to be located at strategic points within the networks of 
the access providers and inter-exchange carriers. An 
interesting problem is the development of algorithms 
and tools that automatically balance the hierarchy by 
re-positioning the caches themselves, not just the 
cached information. Schemes such as dynamic 
hierarchical caching [2] and geographical push-caching 
[3] begin to address this issue. 

A further argument in favor of using active 
technologies for web caching is that a significant 
fraction of web pages are dynamically computed and 
not susceptible to traditional (passive) caching. This 
suggests the development of web proxy schemes that 
support "active" caches that store and execute the 
programs that generate web pages. 

Mobile/Nomadic Computing 

Interposition strategies are used by a number of 
researchers addressing mobility. For example, 
Kleinrock [4] describes a "nomadic router" that is 
interposed between an end system and the network. 
This module observes and adapts to the means by 
which the end system is connected to the network, e.g., 
through a phone line in a hotel room versus through the 
LAN in the home office. It might decide to perform 
more file caching or link compression when the end 
system is connected through a low bandwidth link 



and/or invoke additional security, such as encryption, 
when operating away from the home office. 

Similarly, "nomadic agents and gateways" [4] are 
nodes that support mobility. They are located at 
strategic points that bridge networks with vastly 
different bandwidth and reliability characteristics, such 
as the junctions between wired and wireless networks. 
Application-neutral work on TCP snooping [5] improves 
the performance of TCP connections by retaining per- 
connection state information at wireless base stations. 
Application-specific services performed at gateways 
include file caching and the transcoding of images [6]. 
The InfoPad [7] takes the process even further, by 
instantiating user-specific "pad servers" supporting a 
range of applications, such as voice and hand-writing 
recognition, at intermediate nodes. 

New Application Domains 

There is an untapped reservoir of applications that 
require sophisticated network-based services to support 
the distribution and fusion of information. One 
promising direction is the development of multi-point 
communication strategies that are more flexible than 
the existing IP multicast service, which performs a 
very limited computation on the user data, i.e., 
copying. Application-specific multicast, for example, 
would provide the mechanism to realize the quality of 
service filtering suggested in [8] for video-conferencing. 

Information fusion is an example of a domain that 
may leverage interposed computation. Applications 
such as sensor fusion, simulation and remote 
manipulation, allow users to "see" composite images 
constructed by fusing information obtained from a 
number of sensors. Fusing data within the network 
reduces the bandwidth requirements at the users, who 
are located at the periphery of the network. Placing 
application-specific computation near where it is 
needed also addresses latency limitations by shortening 
the critical feedback loops of interactive applications. 

3. ACTIVE NETWORKS 

In this section, we provide an overview of active 
networks - highly programmable networks that perform 
computations on the user data that is passing through 
them. We distinguish two approaches to active 
networks, discrete and integrated, depending on 
whether programs and data are carried discretely, i.e., 
within separate messages, or in an integrated fashion. 
We then provide a high-level description of how active 
nodes might be organized and describe a node 
programming model that could provide the basis for 
cross-platform interoperability. 

3.1 Programmable Switches - A Discrete Approach 

The processing of messages may be architecturally 
separated from the business of injecting programs into 
the node, with a separate mechanism for each function. 
Users would send their packets through such a 
"programmable" node much the way they do today. 



When a packet arrives, its header is examined and a 
program is dispatched to operate on its contents. The 
program actively processes the packet, possibly 
changing its contents. A degree of customized 
computation is possible because the header of the 
message identifies which program should be run - so it 
is possible to arrange for different programs to be 
executed for different users or applications. 

The separation of program execution and loading 
might be valuable when it is desirable for program 
loading to be carefully controlled or when the 
individual programs are relatively large. This approach 
is used, for example, in the Intelligent Network being 
standardized by CCITT. In the Internet, program 
loading could be restricted to a router's operator who is 
furnished with a "back door" through which they can 
dynamically load code. This back door would at 
minimum authenticate the operator and might also 
perform extensive checks on the code that is being 
loaded. Note that allowing operators to dynamically 
load code into their routers would be useful for router 
extensibility purposes, even if the programs do not 
perform application- or user-specific computations. 

3.2 Capsules - An Integrated Approach 

A more extreme view of active networks is one in 
which every message is a program. Every message, or 
capsule, that passes between nodes contains a program 
fragment (of at least one instruction) that may include 
embedded data. When a capsule arrives at an active 
node, its contents are evaluated, in much the same 
way that a PostScript printer interprets the contents of 
each file that is sent to it. 

Figure 1 provides a conceptual view of how an 
active node might be organized. Bits arriving on 
incoming links are processed by a mechanism that 
identifies capsule boundaries, possibly using the 
framing mechanisms provided by traditional link layer 
protocols. The capsule's contents are dispatched to a 
transient execution environment where they can safely 
be evaluated. We hypothesize that programs are 
composed of "primitive" instructions, that perform 
basic computations on the capsule contents, and can 
also invoke external "methods", which may provide 
access to resources external to the transient 
environment. The execution of a capsule results in the 
scheduling of zero or more capsules for transmission on 
the outgoing links and may change the non-transient 
state of the node. The transient environment is 
destroyed when capsule evaluation terminates. 

3.3 Programming With Capsules 

Our distinction between the discrete and integrated 
approaches is one of perspective, primarily useful as a 
basis for comparing two ways of thinking about 
networks and their programming. In practical terms, a 
network based on the integrated approach could be 
programmed to emulate the discrete approach and 
vice-versa. Nonetheless, we are intrigued by the 
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possibilities afforded by the integrated perspective, 
especially with respect to new ways of leveraging 
computation within the network. It provides a 
programming language framework for thinking about 
networks - a framework that could enable the synthesis 
of recent results in the areas of programming 
environments, operating systems and networks. 

In the following paragraphs we discuss some ways 
in which active networks could be leveraged to support 
a variety of traditional functions, such as IP packet 
processing, connections, flows, routing protocols, etc. 
These examples are meant to provide insight into the 
"flavor" of the networks we envision and establish the 
groundwork for the discussion of the programming 
model and implementation technologies which follows. 

In simple applications, a capsule's actions on 
visiting a node are to compute its "next hop" 
destination(s) and schedule zero or more (possibly 
modified) copies of itself for transmission on selected 
links. It will be necessary to provide mechanisms for 
determining and naming the links on which outgoing 
capsules are transmitted. In the IP protocol, this 
mechanism is "built-in" to every node and individual 
packets need only carry their destination address - they 
need not have knowledge of the links they traverse. In 
pure source routing schemes, each message carries the 
identities of all of the links it traverses. We hope to 
develop an intermediate approach, in which capsules 
can dynamically enumerate and evaluate the paths 
available at a node, without requiring detailed 
knowledge at the time the capsule is composed. 

An important question concerns the degree to which 
a capsule program can access objects, such as routing 
tables, that lie beyond the transient execution 
environment. In a restricted approach, capsules could 
be largely self-contained. Although sufficient to 
implement some interesting programs, e.g., the above- 
mentioned source routing, this model is somewhat 
confining. In the following paragraphs we discuss three 



ways in which programs could reach beyond the 
capsule's transient environment: 

• Foundation Components - universally available 
services implemented outside of the capsule. 

• Active Storage - the ability to modify the state 
that node storage is left in at the completion of 
capsule execution. 

• Extensibility - allowing programs to define new 
classes and methods. 

Foundation Components 

Foundation components implement external 
"methods" that provide controlled access to resources 
outside of the transient execution environment. A 
subset of these components will reflect the "API" of 
the node's run-time environment to the applications. 
Other components provide a built-in class hierarchy 
that serves as a base for the development of capsule 
programs. 

Many capsules will require access to other node- 
specific information and services, such as routing 
tables and the state of the node's transmission links. 
Using built-in components that provide access to this 
information, one could design capsules whose 
evaluation performs similar processing to that 
performed on the header of an IP datagram. Multi-cast 
and option processing instructions could be included in 
the capsules that require them. Whereas the traditional 
IP approach calls for the code to be fixed and built into 
the router, in the active case the program is flexible 
and carried with the data. 

For migration purposes, we could develop 
standardized components that implement the existing 
Internet protocol types. A capsule carrying an 
embedded IPv4 datagram could contain a single 
instruction of the form "execute the IPv4 method on 
the remainder of the payload". To put matters in 
perspective, we can think of existing routers as an 



extremely restricted subset of active nodes, in which 
the capsule "program" is carried in the IP protocol type 
field. The instruction set is restricted to pre-defined 
methods that correspond to the known protocol type 
field values and implement the standardized 
functionality specified by the IETF. 

Active Storage 

It would be advantageous if capsules could leave 
information behind in a node's non-transient storage. 
One might open a connection by arranging for a 
capsule to be executed at each node along a specific 
path, and having it leave a small amount of associated 
state in each node it traverses. Subsequent packets 
following this path would include code that locates and 
evaluates the connection state at each node. 

A similar approach could be used to realize "flows" 
[9], which are somewhat softer than connections. 
Every capsule would include code that attempts to 
locate and use its "flow" state at the nodes it traverses. 
However, flow capsules are somewhat more robust than 
those used during connections in that the flow state is 
not essential to the capsule's successful execution. If a 
flow capsule encounters a node that has no relevant 
state information, it dynamically generates the required 
data, uses it for its own purposes, and leaves it behind 
for the convenience of later capsules. The network 
nodes can treat flow states as "soft state" values that 
are cached and can be disposed of if necessary. In this 
respect, flows are less demanding than connections on 
the robustness of node storage. Of course, our active 
connections and flows are considerably more powerful 
than those of present day systems, in that the "state" 
left behind is in the form of programs rather than static 
table entries. 

Eventually, we hope to develop new schemes that 
go beyond traditional connections and flows. For 
example, capsules could be programmed to rendezvous 
at a node by arranging for the first arriving capsule to 
set some state information and then "sleep" until the 
remaining capsules have arrived. The capsules could 
then engage in some joint computation, such as may 
be used in sensor fusion applications or the pruning of 
multi-cast trees. 

Finally, we note that capsules capable of modifying 
the node's storage provide a uniform mechanism for the 
implementation of background node functions. Routing 
protocols and table updates could be implemented in 
capsules as could network management functions, such 
as those provided by SNMP. Long-lived housekeeping 
functions could also be implemented in this manner, 
though in their case the "transient" execution 
environment might survive until the node is reset. 

Program Extensibility 

Unless programs are short relative to the data they 
encapsulate, it will prove inefficient for them to be 
carried in individual messages. Accordingly, it makes 
sense for the programming environment to be 



extensible, so that capsules can "plant" uniquely 
named classes and methods at nodes, for reference by 
other capsules and methods. In this' way, most 
capsules can be concise - possibly a single instruction 
that invokes a user-specific method on the remainder of 
the capsule contents. 

An interesting scheme would be to provide a 
mechanism that dynamically resolves references to 
external methods. Instead of capsules explicitly 
loading methods into the s non-transient storage of the 
node, the node could contain a "cache" of known 
external methods and be equipped with a mechanism 
that allows it to locate and dynamically load methods 
on demand. 1 Although such a "demand" approach 
might suffer latency problems when a new application 
is started, this could be offset by allowing capsules that 
prime the cache when faults are anticipated. 

The distinction between the "explicit" and 
"demand" loading schemes is closely related to the 
broader distinction we have made between discrete and 
integrated approaches to active networks. The explicit 
and discrete cases distinguish program loading as an 
explicit activity that must be completed prior to usage. 
In contrast, the demand and integrated cases offer 
increased flexibility with respect to determination and 
timing. Of course, this flexibility comes at some cost 
in terms of the sophistication of the mechanisms 
required to support safe and efficient loading. 

3.4 Towards an Interoperable Programming Model 

To be of general utility, capsules require: mobility, 
so that programs can be transmitted across the network; 
and portability, so that they can be loaded into a range 
of platforms. This suggests the development of a 
relatively small number of standardized models for the 
programming of network nodes and the description and 
allocation of their resources. Our objectives for such 
models are that they support: 

• Mobility - the ability to transfer capsules and 
execute them on a range of platforms that 
leverage different underlying technologies. 

• Safety - the ability to restrict the resources that 
capsules can access. 

• Efficiency - enabling the above without 
compromising network performance, at least in 
the most common cases. 

Traditional packet networks achieve interoperability 
by standardizing the syntax and semantics of packets. 
For example, Internet routers all support the agreed IP 
specifications; although router implementations may 



*An interesting approach to resolving cache "faults" 
would be for a node to request the method from the node that 
sent it the faulting capsule - forming a chain back to the 
originator of the capsule who could be expected to take 
ultimate responsibility for resolving the reference. Of 
course, the originator might do so by demand loading the 
code from their software vendor. 



differ, they implement roughly "equivalent" programs. 
In contrast, active nodes can execute many different 
programs, i.e., they can perform very different 
computations on the packets flowing through them. 
Network interoperability is achieved at a higher level 
of abstraction - instead of standardizing the 
computation performed on every packet, we 
standardize the computational model, i.e., the 
instruction set and resources available to capsule 
programs. 

We find it convenient to distinguish between: issues 
surrounding the representation and evaluation of the 
capsules themselves; and safe access to node 
resources. 

In section 4, we outline the functionality that is 
required and discuss mechanisms that can be used to 
support the safe and efficient execution of capsules. 
We discuss how "active technologies", developed 
within the programming language and operating system 
communities, can be used to prevent unauthorized 
access to resources that lie beyond the boundaries of 
the transient execution environment into which a 
capsule is dropped. 

In section 5, we discuss resource management, 
which is an important issue in active nodes - these 
nodes are components of the shared infrastructure and 
their users must be protected from each other to a 
degree that is typically not required within personal 
computers or even group servers. The programming 
model must deal with two issues associated with node 
resources: interoperability and resource management. 
The interoperability requirement is for a common 
model of the resources available at a node. Resource 
management issues include resource allocation and 
capsule authentication and authorization. 

4. CAPSULE PROGRAMS - MOBILITY, SAFETY 
AND EFFICIENCY 

In this section we discuss: the languages in which 
capsule programs are expressed; and mechanisms that 
can support their safe and efficient execution. Our 
overall approach is to evaluate each capsule within the 
context of a transient execution environment whose 
lifetime is the interval during which the capsule is 
evaluated at a given node. Safety properties are 
provided by restricting the actions that can be 
performed and their scope, e.g., their access to storage 
and other node resources. 

4.1 Capsule Primitives 

There is a limited set of primitive actions that 
capsules can perform without straying beyond their 
transient environments. These actions constitute a 
restricted programming language, or instruction set, 
that can perform: arithmetic and branch operations; and 
manipulate stack and heap storage of the transient 
environment. 



The set of primitive actions will be extended 
through the addition of external method invocation, 
which provides access to resources beyond the 
transient environment. Some of these external methods 
will leverage the same primitive actions and will also 
be evaluated in a closed environment, i.e., with a sharp 
distinction between their self-contained actions and 
their access to other methods. Others will access the 
built-in "API" of the node's run-time environment or 
embedded operating system. The API of active 
network nodes will be distinguished by the availability 
of methods that are tailored to the network 
environment, such as the efficient copying of capsules 
and sophisticated control over the scheduling of 
transmission resources. 

For interoperability purposes all of the active nodes 
along a capsule's path should be capable of evaluating 
the capsule's contents. 2 There are three well known 
ways of achieving this level of portability/mobility: 

• Express the programs in a high-level source 
language that may be interpreted at the nodes; 

• Adopt a platform independent intermediate 
representation, typically a byte coded "virtual" 
instruction set; 

• Express the programs in a platform-dependent 
binary format and arrange for each capsule to 
carry multiple encodings of its program - one for 
each type of platform that it traverses. 

We expect to leverage all three approaches. 
Source encodings will prove useful for rapid 
prototyping. An intermediate representation may 
provide a compact and relatively efficient way to 
express relatively short programs. . External methods 
could be similarly encoded or could be expressed in a 
machine dependent format. We expect that heavily 
used components will be packaged in binary libraries, 
especially "bootstrap" libraries that allow 
administrators to initialize newly installed or repaired 
platforms. 

4.2 Safe and Efficient Execution 

One of the reasons that we believe it will be 
possible to realize active networks is the availability of 
active technologies - mechanisms that allow users to 
inject customized programs into shared resources. 
Active technologies are not new. However, our use of 
active technologies within the network is novel - until 
now the use of active technologies in networking has 
been end-to-end (e.g., shipping code from servers to 
clients or vice- versa). In the case of active networks, 
the shared resources in question are the routers, 
switches and servers that lie within the network. Our 



^ At each hop, a capsule could translate itself into the 
language that is understood by the "next hop" node along its 
path. However, this approach seems extreme - even by our 
standards! 



work will leverage and extend the presently available 
technologies. 

Active Technologies - Background 

Active technologies have been emerging in the 
fields of operating systems and programming languages 
for over ten years. Early work tended to address only 
one of three important issues - mobility, efficiency qz 
safety. PostScript is an example of an early effort that 
stressed mobility over safety. Applications generate 
mobile programs that are executed at printers, which 
may be shared and distributed about a network. 

In the field of parallel processing, "active 
messages" [10, 11] stressed efficiency over mobility by 
reducing the "program" to a single instruction - each 
message invokes an application-specific handler 
resident at the recipient. The handler provides a low 
overhead mechanism for dispatching arriving 
messages, so that they can be treated as self- 
scheduling computations. These systems, which 
targeted communication internal to a single parallel 
processor complex, did not address the safety issues 
relevant to shared infrastructures. 

The advent of heterogeneous distributed systems 
and internetworking has accelerated the pace of 
research. The x-kernel [12] supports the composition of 
protocol handlers by providing a regular architecture for 
stacking them and by automating the dispatch process. 
Other efforts [13-15] have focused on less friendly 
environments by improving both the safety and 
efficiency with which handlers can be implemented. 
Most recently, there have been efforts to jointly 
address all three issues - mobility, safety and 
efficiency - under the banners of configurable 
operating systems, agents, mobile applets and other 
schemes related to the World Wide Web. 

Leveraging Active Technologies 

Active networks will adapt and extend active 
technologies for use within the network.* In general, 
these technologies provide for safe execution by 
restricting the set of primitive actions available to 
mobile programs and the scope of their operands, e.g., 
their access to storage and other resources. An 
interesting question is how to organize the closures 
which provide the basis for safe execution. Our starting 
position is that the namespace of a capsule is restricted 
to the transient environment. This containment policy 
may be relaxed by initializing the closure with a 
default set of foundation components that all capsules 
are allowed to dispatch. Any capsule that accesses 
methods outside of that space must first request that its 
closure be extended by authenticating itself to a 
mechanism that validates its authorization. 

In the following paragraphs, we discuss the 
available technologies in terms of the program 
encoding approaches - source, intermediate, or 
platform dependent binary - and then introduce "on- 



the-fly" compilation, a complementary technology that 
is also of interest. 

Sourpe Code 

Safe -Tel [16] is an example of a language that 
achieves safety through interpretation of a source 
program and closure of its namespace. The safety of 
such a system derives from the restricted closure and 
the correctness of the interpreter, which can prevent 
programs from deliberately or accidentally straying 
beyond the transient execution environment. The 
advantage of the Tcl-based approach is that programs 
are human readable and simple programs can be 
composed quite quickly. Furthermore, TcPs character- 
based representation makes it easy to design programs 
that generate new source fragments. The principal 
disadvantage is the overhead of source code 
interpretation, which is compounded by Tcl's encoding 
of all data types as strings. An additional disadvantage 
is the overall size of programs, which could be 
reduced, albeit at the expense of readability, through 
the use of compression. 

Intermediate Code 

Java [17] achieves mobility through the use of an 
intermediate instruction set [18]. Traditionally, the 
safe execution of intermediate code has relied on the 
careful interpretation of the intermediate instruction 
set. One of Java's key contributions is the observation 
that a significant improvement in efficiency can be 
achieved by off-loading some of the responsibility from 
the interpreter. The instruction set, and its approved 
usage, are designed so as to reduce the degree of 
operand validation that the interpreter must perform as 
each instruction is executed. In part, this is enabled by 
the design of the instruction set, which precludes 
certain cases that would normally have to be checked. 
It is also enabled by the static inspection of code 
before it is first executed, so that many of the checks 
need only be performed once, typically when the 
program is first loaded. 

Elatfora-depqpdent (fimxy) Cc-dq 

The most aggressive of the active technologies 
provide for the execution of platform-dependent binary 
programs that, for the most part, are directly executed 
by the underlying hardware. To safely execute such 
program fragments, one must restrict their use of the 
instruction set and address space. The traditional 
operating systems approach has been to rely on fairly 
heavyweight mechanisms, such as processes and 
hardware-supported address space protection. 
However, there has recently been progress on two 
lighter-weight approaches: 

• The SPIN project [14] relies on the properties of 
the Modula 3 language and a trustworthy 
compiler to generate programs that will not stray 
beyond a restricted environment. When a 
program is presented for execution, the run-time 
system verifies that the instruction sequence was 



generated by a trusted compiler and has not been 
modified. 

• The approach described in [19, 20] prescribes a 
set of rules that instruction sequences must 
adhere to, such as restrictions on how address 
arithmetic is performed. In conjunction with a 
modicum of run-time support and a collection of 
clever techniques, these rules define a 
"sandbox" within which the program can do 
what it likes, but that it may not escape from. 
An important aspect of this work is that 
conformance to the "rules" can be statically 
verified when an instruction sequence is 
presented for execution. 
In both cases, it is assumed that sophisticated 
compiler technology will be used to generate "safe" 
code. The distinction is whether the code is 
independently validated by the receiving platform or 
whether the compilers and/or vendors of programs are 
trusted and authorized to "sign for" their code. 3 The 
former approach improves mobility, especially across 
administrative boundaries. The latter approach not 
only saves the overhead of validation, but might also 
allow the compiler to generate code that is more 
efficient. In both cases, we would expect the directly 
executable binary code to out-perform an interpreted 
format. 

On-the-fly CQmpilatjjpn. 

Recent work [21] has enabled "on-the-fly" 
compilation with a dialect of the C programming 
language. This allows source programs to be 
automatically tailored, or even wholly generated, at 
run-time. In conjunction with sandboxing, such a 
technology could allow active nodes to perform their 
own source-binary translations on capsules they are 
processing. 

On-the-fly compilation technologies may prove 
crucial to the viability of our architecture. Modern IP 
routers achieve reasonable performance through careful 
tuning of their "fast paths", typically by optimizing a 
minimal instruction sequence that processes the vast 
majority of the traffic and relegates the more complex 
(and less frequently used) cases to other modules. An 
active node might achieve a similar performance boost 
by monitoring its traffic and dynamically generating a 
fast path program that streamlines the execution of the 
most common capsule programs. Techniques such as 
scheduling by path (found in Scout [22]) may also be 
applicable. 

Discussion 

Variability in network applications and traffic 
patterns suggests that there is no right answer. 
Although the performance that can be gained through 
binary encodings is attractive, it comes at the cost of 



3we assume the availability of appropriate authentication 
and tamper-proof signature technology. 



portability. Furthermore, the instruction encodings 
associated with modern processors are far from 
compact - these schemes might give rise to much 
larger capsules than an intermediate encoding, 
suggesting a trade-off between transmission bandwidth 
and processing capacity. Finally, node implementors 
designing for high risk environments, i.e., focusing on 
safety, may prefer interpretation-driven schemes that 
audit the execution of each instruction. 

Our plan is to adopt a Java-like instruction set as 
the basis for ActiveNet interoperability and code 
mobility. One of the benefits of the present IP packet 
format is that it enables an "hourglass" architecture in 
which a variety of upper layer protocols can operate 
over a wide range of network substrates. An 
intermediate instruction set will provide an analogous 
hourglass that facilitates mobility. A range of 
programming languages and compilers can be used to 
generate highly mobile intermediate code that can be 
executed on a wide range of hardware platforms. 

Nonetheless, we believe that it will also prove 
practical and attractive to provide extensions that 
allow users and node implementors to leverage source 
and binary technologies. The architectural trick will be 
to enable these technologies, while retaining the 
intermediate instruction set as a fallback point that 
ensures interoperability. We have considered the 
following extensions: 

• Allow programmers to optimistically leverage a 
source programming language, such as Safe-Tel, 
in the hope that it is supported at the nodes a 
capsule traverses. A node that is not equipped 
with the appropriate interpreter or translator 
could either demand load one or forward the 
capsule to some other node that can translate it 
to the intermediate representation. 

• Allow "fat" capsules that carry binary encodings 
(for popular platforms) alongside their 
intermediate encodings. 

• Have nodes track their use of external methods, 
identifying candidates for binary encoding. A 
node could leverage on-the-fly technology to 
translate such methods locally, or it could load 
platform-specific versions from elsewhere on the 
network. 

• The previous suggestion might be combined with 
demand loading. A node can identify its platform 
type whenever it requests an external method, 
affording the supplier the option of returning a 
binary encoding should an appropriate one be 
readily available. 

4.3 Summary 

In this section, we have outlined our approach to 
the safe and efficient evaluation of capsules* Although 
it is useful to distinguish between the program 
representation and its implementation, we realize that 
the two will strongly influence each other. The choice 



of programming environment is going to preferentially 
favor certain implementation strategies, and at the 
same time implementation strategies that lead to 
efficiency or greater security (or simply become more 
popular) are going to influence the programming 
environment. 

Having identified the requirement for common 
programming models, we are not suggesting that a 
single model be immediately standardized. The 
tensions between available programming models and 
implementation technologies can sort themselves out 
in the research "marketplace" as diverse experimental 
systems are developed, fielded, and accepted or 
rejected by users. For example, if the marketplace 
identifies two or three encodings as viable, then nodes 
that concurrently support all of them will emerge. As 
systems evolve to incorporate the best features of their 
competitors, we expect that a few schemes will 
become dominant. 

5. NODE RESOURCES - INTEROPERABILITY 
AND SAFETY 

Active networks will provide the building blocks for 
a shared information infrastructure that transcends 
many administrative domains. Accordingly, their 
design must address a range of "sharing" issues that 
are often brushed over in systems that are used in less 
public environments. We focus on two of the issues 
that must be addressed. For interoperability, capsule 
programmers must have a shared understanding as to 
what the resources are and how they are named. 
Secondly, mechanisms must be provided to limit 
access to scarce or sensitive resources. 4 

5.1 Interoperability - Resource Specification 

The complexity of a system in which every capsule 
leverages a wide range of resources - each of which 
must be named, have its attributes specified and be 
carefully allocated - could explode quite quickly. 
Fortunately, most capsules will not require 
sophisticated resource models. We propose a 
relatively spartan approach employing a small set of 
platform independent abstractions for the physical 
resources of a node: transmission bandwidth, 
processing capacity, and transient storage. Additional 
flexibility is provided through longer term storage and 
logical resources, used by advanced applications, such 
as topology discovery, routing, and network 
management. 

Transmission Bandwidth 

Link bandwidth is typically not considered by the 
scheduling or resource allocation schemes of 



4 There may be a further requirement to control the 
scheduling of some resources, such as transmission 
bandwidth. There may also be requirements for resource 
metering, accounting and/or auditing. 



conventional operating systems. The link abstraction 
must encompass the units of bandwidth allocation and 
may take account of the traffic patterns that are 
generated. A detailed approach could draw on the 
service model [23] activities of the IETF. In some 
environments, simpler schemes may be possible, e.g., 
allowing each capsule program to consume a quantity 
of transmission bandwidth that is proportional to the 
size of the capsule it arrived in. 

Instruction Execution (CPU) 

It is somewhat easier to abstract a node's 
instruction processing resources - even multiprocessors 
tend to be homogeneous and their aggregate capacity 
is more or less established through industry 
benchmarks. In many cases, it will be sufficient to 
assign every capsule a default allocation that guards 
against runaway computations. However, the ability to 
trade computation against bandwidth may be useful to 
encourage, for example, compression prior to 
transmission on low bandwidth links. 

Transient Storage 

The transient execution environment consumes 
short term storage, which might also be limited. We 
tend to think of storage capacity along two axes: the 
storage utilized during specific intervals and the 
duration of those intervals: The former can be 
addressed by placing a default bound on the transient 
storage that can be allocated during capsule 
evaluation. The latter is somewhat trickier. We 
expect that most capsules will complete their 
execution quickly, i.e., in a few milliseconds or less. 
However, some capsules may linger, especially those 
that must rendezvous with others. This issue might be 
addressed by establishing a policy that permits the 
"garbage collection" of inactive capsules during times 
of shortage and requires capsules that are deliberately 
"sleeping" to place themselves in hibernation within 
longer term active storage. 

Active Storage 

We have identified requirements for the storage of 
components, such as external methods and data, that 
survive the execution of individual capsules. We find 
it useful to distinguish between two types of active 
storage, soft and persistent. Soft storage is used to 
cache objects, such as "hints", "flow state" or demand 
loaded components, that do not survive the re- 
initialization of a node. They can be deleted from the 
store without notice and their contents regenerated or 
reacquired if they are later needed. Given that this 
space is easily reclaimed, limits on its allocation may 
not be as important as the strategy that selects 
"victims" for reclamation 5 . Persistent storage provides 
a longer term abstraction for information that must be 
reliably stored, such as logs that are intended for 



^ Mechanisms such as those described in [24] might be 
used to "page" soft state to/from nearby nodes. 



accounting and auditing purposes. This storage may 
also be used by applications that implement 
asynchronous multi-cast services, such as news 
distribution groups. Although this storage abstraction 
will be available at most nodes, it may be 
implemented by accessing replicated storage services 
located elsewhere on the network. We hope to 
leverage technologies such as [25] for this purpose. 

Logical Resources 

Although there are a relatively small number of 
physical resources, a node may support a large number 
of logical resources of many different types. This 
suggests the need for a uniform (not necessarily global) 
mechanism for naming instances of logical resources, 
including dynamically created resources, such as soft 
and persistently stored components. Fortunately, there 
is an abundance of past work on object naming 
schemes. 

The class specifications of many logical resources, 
such as application-specific external methods or flow 
states, may be private in the sense that they need only 
be known to capsules generated by the relevant 
application. However, there will be a need for 
interoperable class specifications for some resources, 
such as routing tables. In this case, we hope to 
leverage existing notations, such as those used for 
SNMP Management Information Bases (MIBs). 
Where possible, we will leverage the existing MIB 
specifications themselves, which should facilitate 
interoperation between the ActiveNet and the existing 
Internet. 

5.2 Resource Safety 

The safe manipulation of node resources can be 
partitioned into three types of activities: 

• dynamic, yet safe, assignment of resources to 
specific capsules. 

• validation of user requests for resource 
assignment, through authentication and 
verification of their authorizations. 

• automated delegation of resource authorizations. 

Dynamic Assignment 

Recall that our overall plan is to leverage the 
closure/addressability limitations enforced by active 
technologies. Resources are always represented and 
accessed through external methods and the default 
resources available to a capsule are included in the 
closure with which it is initiated. There is a further 
requirement for a mechanism that supports dynamic 
resource allocation. This can be accomplished by 
providing an external method that allows a program to 
request the safe "extension" of its closure. 

Validation 

The mechanism performing validation must 
authenticate the capsule source, check that it is 
authorized to access the resource and (possibly) verify 



that the resource request has not been tampered with. 
This mechanism need only be used in conjunction with 
requests for additional resources. 

We assume that cryptography will provide the basis 
for the validation mechanism, but we may use a 
combination of schemes to reduce per-capsule 
overheads. For example, a public key scheme could 
be used to perform an initial authentication that 
establishes "soft state" that is then used by a lighter 
weight per-capsule signature algorithm. We are 
particularly interested in recent work on inexpensive 
techniques that provide less security for individual 
messages, but defend against large scale attacks [26]. 

Delegation 

The preceding section assumed that the validation 
mechanism has access to information concerning 
authorizations, e.g., policy-initiated decisions as to the 
resources that can be made accessible to specific users 
or applications. We require a mechanism that supports 
the automated delegation of authorizations, in 
accordance with a straightforward model that both 
implementors and administrators can reason about. 
This issue was previously considered within the context 
of time-sharing systems [27, 28] but we are not aware 
of work that addresses delegation in as complex a 
system as the ActiveNet. Work on the cascading [29] 
and logic [30] of authentication, which has some of the 
delegation flavor we are looking for, may provide a 
starting point for further research. 

Ultimately, this may be one of the most important 
"open" questions with respect to active networks. We 
envision an ActiveNet with as many or more 
administrative domains as the Internet (which is still 
growing), and administrators will be swamped if they 
are expected to manually coordinate the detailed 
authorization information This is another place where 
complexity, in this case administrative complexity, 
could overwhelm the infrastructure. 

6. FROM INTERNET TO ACTTVENET 

We suggest that interested researchers- pool their 
talents in an effort to deploy a wide area ActiveNet. 
This experimental infrastructure could be overlaid on 
existing substrates, such as the Internet and the VBNS, 
obviating the need for dedicated transmission facilities. 
Although most of the ActiveNet nodes could be located 
at participating research sites, provision should be 
made to locate nodes at strategic locations not 
normally accessible to researchers, e.g., the NAPs of 
the Internet. If a research ActiveNet proves successful, 
it could be extended to assume direct control over the 
underlying transmission resources. 

In assembling a collection of nodes into an 
ActiveNet it will be necessary to deal with many of the 
issues that have been addressed in the design of the 
current Internet - topology discovery, routing, etc. 
Initially, we expect to adopt the techniques used in the 
Internet. However, researchers should also investigate 



new algorithms that leverage the availability of active 
nodes. 

Eventually, it will be important to converge on an 
interoperable programming model that will achieve for 
active networks what IP standardization has for the 
Internet. However, the connectivity available through 
existing substrates will makes it possible to deploy a 
multiplicity of programming models in parallel, 
affording the research community an opportunity to 
explore alternative programming models and node 
implementations. It will be particularly important to 
engage application developers and users in the 
development of customized software components that 
exercise this "architecture of architectures". 

7. ARCHITECTURAL CONSIDERATIONS 

Conventional network architectures separate the 
upper (end-to-end) layers from the lower (hop-by-hop) 
layers. The network layer bridges these domains and 
enables interoperability by providing a fixed 
application- and user- neutral service that supports the 
exchange of opaque data between end systems. 

Active networks challenge this traditional thinking 
in a number of ways: the computations performed 
within the network can be dynamically varied; they 
can be user- and application-specific; and the user data 
is accessible to them. We realize that this break with 
tradition raises a number of important questions, some 
of which are addressed in the following responsa. 

How is interoperability achieved? 

The key to interoperability is the network layer 
service, which is at the narrow point of the "hourglass". 
In the case of the Internet [9], there is a detailed 
specification of the syntax and semantics of the IP 
protocol, which must be implemented by all of the 
routers and communicating end systems. In effect, 
interoperability is supported by requiring that all of the 
nodes perform "equivalent" computations on the 
packets flowing through them. 

In contrast, active nodes are capable of performing 
many different computations (i.e., executing many 
different programs) for different groups of users. 
However, the nodes must all support an "equivalent" 
computation model. Thus, network layer 
interoperability is based on an agreed program 
encoding and computation environment instead of a 
standardized packet format and fixed computation. 

Architecturally, we are bumping up the level of 
abstraction at which interoperability is realized. There 
is still an hourglass - but the abstraction at its thinnest 
point has been made programmable. 

Isn't the trend towards less functionality in the 
network? 

The long term trend has actually been towards 
increased computation within the network. Whereas 
telephony circuit switches restrict computation to call 



setup time, packet switches perform computations on 
the header of every packet flowing through them. 
Active nodes extend the domain of computation to 
include the user data. 

It is the "intelligence" or control over the network- 
based computation that has been migrating to the 
edges, allowing users to exercise greater control over 
their networks. Experience suggests that the two go 
hand in hand - increasing the flexibility of the 
computation performed within the network enables the 
deployment of even greater computational power at the 
edges. 

What's the impact on the layered reference model? 

There is presently a disconnect between what users 
consider to be "inside" the network and the 
practitioner's perspective, which is somewhat 
restricted. For example, web browsers allow users to 
interact with what they perceive to be "the network" 
without distinguishing among the many routers, domain 
name servers, and web servers that conspire to provide 
the service. It may be time for practitioners to re- 
evaluate their abstractions and start thinking about the 
network at a higher level. 

Current thinking concerning network architecture 
has its roots in the layering of abstractions codified in 
the OSI Reference Model [31]. Although the model 
has proven quite useful it is showing cracks that should 
be addressed: 

• Services at or below the network layer are 
presumed to be user- and application- neutral. 

• It deals poorly with upper layer services that are 
physically interposed between communicating 
end points. Application relays can model these 
cases, but they are far from elegant. 

• It does not model the "recursion" that occurs at 
the network layer, i.e., the tunneling of networks 
over each other. 

• The upper layers, which have never been 
particularly satisfactory, are of diminished 
importance, given that active technologies 
enable the exchange of modules that implement 
application-specific protocols. 

We are not certain what form a new model might 
take, but suggest that it will be more component-based 
than layered [32], It might distinguish primitive 
functions, such as cell relaying and IP "fast paths", 
from computationally active functions, including those 
that configure the fast path components. 
Architecturally, these two types of components might 
be viewed as peers rather than layered upon each other. 
Such an architecture might also give rise to new 
hardware activities, such as the development of 
switching technology that "caches" fast paths and is 
highly responsive to active capsules. 

What about the end-to-end argument? 

The "end-to-end argument" [33] concerns the design 
of intermediaries, such as networks, that provide 



services that cannot be made perfectly reliable. Since 
users of these services must provide "end-to-end" 
mechanisms that cope with failures, designers are 
counseled against over-engineering the intermediaries 
by adding significantly to their complexity or overhead, 
i.e., by trying to make them "almost" perfectly reliable. 
Instead, the designer's objective should be an 
"acceptable" level of reliability that does not trigger 
excessive intervention by the end-to-end mechanism. 
The designer is encouraged to strike a balance by 
relying on end-to-end mechanisms to ensure 
correctness, and by leveraging simple and optimistic 
mechanisms to enhance performance, where 
appropriate. 

While locating computation within the network may 
appear to contradict this guideline, we note that the 
argument pertains to the placement of functionality - it 
does not suggest that the choice of functions that are 
appropriately located within the network cannot be 
application-specific. If anything, active networks allow 
this guideline to be followed more carefully, by 
allowing applications to selectively determine the 
partitioning of functionality between the end points and 
intermediaries. 

Why hasn't this been done before? Why try now? 

The approach we are proposing synthesizes a 
number of technologies; programmable node platforms, 
component-based software engineering, and code 
mobility. A few "programmable" networks have been 
developed in the past, and suggestions for object-based 
approaches to network implementation surface every 
few years. However, the previous work has not 
leveraged code mobility within the network, let alone 
within the context of each and every capsule or packet. 

A key enabler of our approach is the availability of 
"active technologies" that enable safe and efficient 
code mobility. The absence of these technologies 
would have precluded similar projects in the past - and 
their recent emergence underscores the timeliness of 
the proposed effort. 

8. CONCLUSIONS 

In this paper we have described our vision of an 
active network architecture that can be programmed by 
its users. We have also called for community 
participation in an effort to develop and deploy a 
research ActiveNet. In the course of this presentation 
we have raised a number of architectural issues and 
research questions that remain to be addressed. 

We expect that active networks will enable a range 
of new applications in addition to the lead applications 
that already rely on the interposition of customized 
computation within the network. However, we believe 
that this work will also have broader implications, on 
how we think about networks and their protocols; and 
on the infrastructure innovation process. 



Programming the Network 

We are applying a programming language 
perspective to networks and their protocols. In place of 
protocol "stacks", we anticipate the development of 
protocol components that can be tailored and 
composed to perform application-specific functions. 
These protocol components will leverage the tools of 
the modern programming trade - encapsulation, 
polymorphism and inheritance. Within our own 
research group, we are setting out to create a 
"Smalltalk of networking" and are interested not just in 
the "language" itself but also in the class hierarchy, 
etc. that will develop around it. 

Our enthusiasm is tempered by the realization that 
suggestions for object-oriented approaches to 
networking surface every five to ten years, and have 
had little impact on mainstream research. However, 
we believe that it is now time to make a large scale 
effort towards their realization. The availability of 
active technologies and lead applications - in 
conjunction with rising processing power and 
bandwidth - presents opportunities that were not 
previously available. 

Infrastructure Innovation 

As the Internet grows it is increasingly difficult to 
maintain, let alone accelerate, the pace of innovation. 
Today, after a concept is prototyped its large scale 
deployment takes about 8 years. The process involves 
standardization, incorporation into vendor hardware 
platforms, user procurement and installation. The 
present backlog within the IETF includes multicast, 
authentication and mobility extensions, RSVP and 
IPv6. 

Active networks will address the mismatch between 
the rate at which user requirements can change, i.e., 
overnight, and the pace at which physical assets can 
be deployed. They will accelerate the pace of 
innovation by decoupling network services from the 
underlying hardware and by allowing new services to 
be demand loaded into the infrastructure. In the same 
way that IP enabled a range of upper layer protocols 
and transmission substrates, active networks will 
facilitate the development of new network services and 
hardware platforms. 

Conventional network routers are based on 
proprietary hardware platforms that are bundled with 
customized software. Active networks present an 
opportunity to change the structure of the networking 
industry, from a "mainframe" mind-set, in which 
hardware and software are bundled together, to a 
"virtualized" approach in which hardware and software 
innovation are decoupled [34]. A market for "shrink- 
wrapped" network software will facilitate innovation 
by: 

• Allowing third parties to develop innovative 
software without customizing their products to a 
specific platform. 



• Removing the software barrier to entry that 
discourages new players from fielding innovative 
hardware, 

• Addressing the "chicken and egg" problem 
associated with new services - vendors are 
hesitant to support services before they gain user 
acceptance, yet the utility of many network 
services is dependent on their widespread 
availability. 

Furthermore, the process will be user-driven. The 
widespread availability of new services will depend on 
their acceptance in the marketplace, without being 
delayed by vendor consensus and standardization 
activities. Similarly, hardware vendors will seek 
competitive advantage by optimizing their platforms to 
suit changing workloads. 

Summary 

Active networks appear to break many of the 
architectural rules that conventional wisdom holds 
inviolate. However, we believe that they build on past 
successes with packet approaches, such as the Internet, 
and at the same time relax a number of architectural 
limitations that may now be artifacts of previous 
generations of hardware and software technology. 

Passive network architectures that emphasize 
packet-based end-to-end communication have served 
us well. However, as our lead users demonstrate, 
computation within the network is already happening - 
and it would be unfortunate if network architects were 
the last to notice. It is now time to explore new 
architectural models, such as active networks, that 
incorporate interposed computation. We believe that 
such efforts will enable new generations of networks 
that are highly flexible and accelerate the pace of 
infrastructure innovation. 
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Active networks are a novel approach to network architecture in which the switches of the network perform customized computations 

on the messages flowing through them. This approach is motivated by both lead user applications, which perform user-driven 
computation at nodes within the network today, and the emergence of mobile code technologies that make dynamic network service 
innovation attainable. In this article, the authors discuss two approaches to the realization of active networks and provide a snapshot of 
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/n an active network, the routers or switches of the network 
perform customized computations on the messages flowing 
through them. For example, a user of an active network could 
send a "trace" program to each router and arrange for the 
program to be executed when their packets are processed. 
Figure 1 illustrates how the routers of an IP network could be 
augmented to perform such customized processing on the 
datagrams flowing through them. These active routers could 
also interoperate with legacy routers, which transparently for- 
ward datagrams in the traditional manner. 

These networks are active in the sense that nodes can 
perform computations on, and modify, the packet contents. 
In addition, this processing can be customized on a per-user 
or per-application basis. In contrast, the role of computa- 
tion within traditional packet networks, such as the Internet, 
is extremely limited. Although routers may modify a pack- 
et's header, they pass the user data opaquely without exami- 
nation or modification. Furthermore, the header 
computation and associated router actions are specified 
independent of the user process or application that gener- 
ates the packet. 

The concept of active networking emerged from discus- 
sions within the broad Defense Advanced Research Projects 
Agency (DARPA) research community in 1994 and 1995 on 
the future directions of networking systems. Several prob- 
lems with today's networks were identified: the difficulty of 
integrating new technologies and standards into the shared 
network infrastructure, poor performance due to redundant 
operations at several protocol layers, and. difficulty accom- 
modating new services in the existing architectural model. 
Several strategies, collectively referred to as active network- 
ing, emerged to address these issues. The idea of messages 
carrying procedures and data is a natural step beyond tradi- 
tional circuit and packet switching, and can be used to rapid- 
ly adapt the network to changing requirements. Coupled 
with a well understood execution environment within net- 
work nodes, this program-based approach provides a founda- 



tion for expressing networking systems as the composition of 
many smaller components with specific properties: services 
can be distributed and configured to meet the needs of 
applications, and statements can be made about overall net- 
work behavior in terms of the properties of individual com- 
ponents. 

In this article we discuss two approaches to the realiza- 
tion of active networks. The programmable switch approach 
maintains the existing packet/cell format, and provides a 
discrete mechanism that supports the downloading of pro- 
grams. Separating the injection of programs from the pro- 
cessing of messages may be particularly attractive when the 
selection of programs is made by network administrators 
rather than individual end users. In contrast, the capsule 
approach goes somewhat further — the passive packets of . 
present-day architectures are replaced by active miniature 
programs that are encapsulated in transmission frames and 
executed at each node along their path. User data can be 
embedded within these capsules, in much the same way a 
page's contents are embedded within a fragment of 
PostScript code. 

Research in active networks is motivated by both technolo- 
gy "push" and user "pull.** The "pull" comes from the assort- 
ment of firewalls, web proxies, multicast routers, mobile 
proxies, video gateways, and so forth that perform ixser-driven 
computation at nodes "within" the network. Some of these 
lead users are described in Table 1. In many cases, these ser- 
vices are implemented at nodes, such as firewalls, which adopt 
the facade of routers but perform application-specific process- 
ing that transcends conventional architectural guidelines. Our 
goal is to replace the numerous ad hoc approaches to net- 
work-based computation with a generic capability that allows 
users to program their networks. 

The technology "push" is the emergence of active tech- 
nologies that make our goals attainable. Until recently, the 
specter of administrators (let alone end users) programming 
their networks has raised insurmountable concerns with 
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respect to infrastructure safety and efficiency. 
However, recent advances in programming lan- 
guages, compilers, and operating systems may 
provide the keys to the safe and efficient execu- 
tion of mobile program fragments. Today, these 
active technologies are applied within individu- 
al end systems and above the end-to-end net- 
work layer (e.g., to allow Web servers and 
clients to exchange Java applets). Active net- 
works leverage and extend these technologies 
for use within the network, in ways that will 
fundamentally change our mindset concerning 
what is "in" the network. 

This article provides a current snapshot of 
active network research activities, including work 
on the underlying active technologies. In the next 
two sections, we describe the impact active networks may have 
on infrastructure innovation and the new applications that will 
be enabled. We then present a framework, or set of issues, 
that can be used to categorize and organize activity within the 
field. Finally, we present a survey of current research activities 
within our own laboratories and elsewhere in the community. 

Accelerating Infrastructure 
Innovation 

Jk s the lead users cited in Table 1 demonstrate, computa- 
tion within the network is already happening; the demon- 
strated demand for these services suggests that network 
architectures must adapt to deal with this new reality. 

At a more fundamental level, the network innovation pro- 
cess is itself ripe for renewal. The pace of network innovation 
is far too slow; and as the Internet grows it is increasingly dif- 
ficult to maintain, let alone accelerate, this pace. To a large 
degree this is a function of the need to achieve consensus: a 
network's utility increases with the number of interconnected 
nodes. Today, the path from prototype demonstration to 
large-scale deployment takes about ten years. The process 




Figure 1 . Application-specific processing within the nodes of an active net- 
work. 



involves standardization, incorporation into vendor hardware 
platforms, user procurement, and installation. The present 
backlog of Internet services includes multicast, authentication 
and mobility extensions, Reservation Protocol (RSVP), and 
Internet Protocol version 6 (IPv6). 

IP enables interoperability by defining a standard packet 
format and addressing scheme; although router implementa- 
tions may differ, they implement roughly "equivalent" pro- 
grams. Thus, the mechanisms for IP innovation are changing 
the IP service, which means changing everything (since it is 
the basis for interoperability); or establishing overlays (e.g., 
theMBone). 

In contrast, active nodes can execute many different pro- 
grams; that is, they can perform very different computations 
on each of the packets flowing through them. Instead of 
insisting that all the routers perform "equivalent" computa- 
tions on every packet, active networks specify that all nodes 
support equivalent computational models (ix., virtual instruc- 
tion sets). Active networks raise the level of abstraction at 
which interoperability is realized, allowing applications to cus- 
tomize message processing to suit their purposes. 

The ability to download new services into the infra- 
structure will lead to a user-driven innovation process in 
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■ Figure 2. Exploiting the network-based merging and distribution 
information. (Diagram courtesy of Prof. Henty Fuchs, UNC) 

which the availability of new services will be dependent on 
their 'acceptance in the marketplace. Active networks present 
an opportunity to change the structure of the networking 
industry from a "mainframe" mindset, in which hardware and 
software are bundled together, to a "virtualized" approach, in 
which hardware and software innovation are decoupled [7]. 
The network programming abstraction provides a powerful 
platform for user-driven customization of the infrastructure, 
allowing new services to be deployed at a faster pace than 
can be sustained by vendor-driven consensus and standardiza- 
tion activities. 

Enabling New Applications 

/l ctive networks will enable new applications that rely on 
A\ network-based merging of information, user-aware net- 
work protection, and active network management 

MERGING AND DISTRIBUTION OF INFORMATION 
The era of multi-user, multisite applications has just begun; 
the success of the MBone and the Web are but harbingers of 
what may lie ahead. There is an untapped, reservoir of appli- 
cations that require network-based services to support the 
merging and distribution of information. However, existing 
systems are based on a service that provides an extremely lim- 
ited function (i.e., the copying of IP packets) without support 
for application-specific distribution, let alone network-based 
storage or information fusion. 

Figure 2 illustrates how sophisticated multisite applications 
will leverage computation and storage within the network. In 
this figure an application, such as simulation or remote manipu- 
lation, allows each user to "see" composite images constructed 
by fusing information obtained from a large number of sen- 
sors. Furthermore, each sensor can be "watched" by a number 
of users, who will have different requirements concerning the 
encoding and presentation of the information they access. 
Merging data within the network reduces the bandwidth 
requirements at the users, who are located at the (low-band- 
width) periphery of the network. Similarly, user-specific multi- 
cast services within the network reduce the load on the 
sensors and network backbone. 

Web proxies that cache pages of information are another 
example of a multi-user service which could benefit from net- 
work-based computation and storage. Harvest [2] employs a 
hierarchical caching scheme that can reduce the latencies 
experienced by individual users and the aggregate bandwidth 
consumed. The cache nodes are presently located near the 
edges of the network, that is, at nodes within the end-user 
organizations. These systems could be extended by allowing 
nodes of the hierarchy to be located at strategic points within 
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the networks of Internet access providers and interex- 
change carriers. An interesting problem is the develop- 
ment of algorithms and tools that automatically 
"balance" the hierarchy by repositioning the caches 
themselves, not just the cached information. A further 
argument in favor of using active technologies for Web 
caching is that a significant fraction of web pages are 
dynamically computed and not susceptible to passive 
caching. This suggests the development of schemes that 
support active caches which store and execute programs 
that generate these pages. 

User-Aware Network Protection 

Protection of information means that the right informa- 
tion gets to the right people at the right place and time. 
Although network security and authentication mecha- 
nisms are being proposed in many networking forums, 
active networking may admit the design of an integrated 
mechanism that governs all network resources and the infor- 
mation flowing through them. This eliminates the need for 
multiple security/authentication systems operating indepen- 
dently at each communication protocol layer. It allows us to 
program in security policy for the network on a per-user or 
per-use basis. Finally, a formal approach using rigorous speci- 
fications and language-enforced-type safety can be used to 
reason about the protection policies and the mechanisms of 
their implementation. 

Active Network Management 

Many network management tasks consist of collecting and col- 
lating data, such as event counts. To provide the most useful 
network management data, such as exception indications, 
intelligence must be used to filter out uninteresting (unexcep- 
tional) events. Active technologies could be used to imple- 
ment sophisticated approaches to network monitoring and 
event filtering. Network components such as routers may even 
assume a degree of responsibility for monitoring themselves 
(e.g., by injecting customized monitoring and diagnostic pro- 
grams into their nearest neighbors). Similarly, active networks 
can provide the flexibility necessary to improve fault detection 
and to update the survivability policies that govern component 
response to correlated failures, such as those caused by earth- 
quakes or malicious intruders. 

A FRAMEWORK FOR 

Active Network Research 

/n this section, we distinguish two approaches to active 
networks, discrete and integrated, depending on whether 
programs and data are carried discretely (i.e., within sepa- 
rate messages) or in an integrated fashion. We then dis- 
cuss common issues related to node. programming and 
interoperability. 

Programmable Switches — A Discrete Approach 

The processing of messages may be architecturally separated 
from the business of injecting programs into the node, with a 
separate mechanism for each function. This preserves the cur- 
rent distinction between in-band data transfer and out-of- 
band management channels. Users would first inject their 
custom processing routines into the required routers. Then 
they would send their packets through such "programmable" 
nodes much as they do today. When a packet arrives at a 
node its header is examined, and the appropriate program is 
dispatched to operate on its contents. 

Separate mechanisms for loading and execution might be 
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I Table 2. Program encoding technolgoies (with labeled columns M, S, and E assessing mobility, safety, and efficiency, respectively), 



valuable when program loading must be carefully controlled. 
Allowing operators to dynamically load code into their 
routers would be useful for router extensibility purposes, 
even if the programs do not perform application- or user-spe- 
cific computations. In the Internet, for example, program 
loading could be restricted to a router's operator who is fur- 
nished with a "back door" through which they can dynamical- 
ly load code. This back door would at minimum authenticate 
the operator and might also perform extensive checks on the 
code being loaded. 

Capsules — An Integrated Approach 

A more extreme view of active networks is one in which every 
message is a program. Every message, or capsule, that passes 
between nodes contains a program fragment (of at least one 
instruction) which may include embedded data. When a cap- 
sule arrives at an active node, its contents are evaluated, in 
much the same way that a PostScript printer interprets the 
contents of each file sent to it 

Bits arriving on incoming links are processed by a mecha- 
nism that identifies capsule boundaries, possibly using the 
framing mechanisms provided by traditional link-layer proto- 
cols. The capsule's contents are then dispatched to a transient 
execution environment where they can safely be evaluated. 
We hypothesize that programs are composed of instructions, 
which perform basic computations on the capsule contents, 



and can also invoke "built-in" primitives, which may provide 
access to resources external to the transient environment The 
execution of a capsule results in the scheduling of zero or 
more capsules for transmission on the outgoing links and may 
change the nontransient state of the node. 

Toward a Common Programming Model 

Network programs must be transmitted across the communi- 
cation substrate and loaded into a range of platforms. This 
suggests the development of common models for: the encod- 
ing of network programs; the "built-in" primitives available at 
each node; and the description and allocation of node 
resources. 

Program Encoding — Our objectives for program encodings 
are that they support: 

• Mobility — the ability to transfer programs and execute 
them on a range of platforms 

• Safety — the ability to restrict the resources that pro T 
grams can access 

• Efficiency — enabling the above without compromising 
network performance, at least in the most common cases 

Mobility may be achieved at several different levels of 
program representation: express the program in a high-level 
scripting language such as Tel; adopt a platform-indepen- 




dent intermediate representation, 
typically a byte-coded virtual 
instruction set (e.g., Java); or 
transfer programs in binary for- 
mats, such as Omriiware. Table 2 
describes recently developed 
enabling technologies that support 
the safe and efficient execution of 
each level of program encoding. We expect that all three 
Approaches will prove useful: source encodings support 
rapid prototyping; intermediate representations provide a 
compact and relatively efficient way to express short pro- 
grams; and commonly used modules might best be expressed 
at the object code level. 

A possible approach to node interoperability would be to 
agree on an intermediate instruction encoding as the back- 
stop for code mobility. Node implementors and users would 
be welcome to leverage alternative encodings, as long as they 
provide mechanisms through which an intermediate encod- 
ing of a program can be obtained or generated. Implemen- 
tors may also leverage techniques, such as dynamic 
("on-the-fly w ) compilation, that optimize common processing 
routines by both converting portable representations to 
native ones and specializing programs to individual contexts. 
Operating system support for more specific strategies, such 
as "path w -based scheduling, protocol code reorganization, 
and low-level extensibility should also prove useful. Table 3 
describes some of these compilation and operating system 
technologies. 

Common Primitives — The services built into each node 
might include several categories of operations [12]: primitives 
that allow the packet itself to be manipulated (e.g., by chang- 
ing its header, payload, and/or length); primitives that provide 
access to the node's environment (e.g., node address, time of 
day, and link status); and primitives for controlling packet 
flow (e.g., forwarding, copying, and discarding). Additional 
primitives might provide access to node storage and schedul- 
ing, for example, to facilitate rendezvous operations that com- 
bine processing across multiple packets. 

Node Resources and Their Allocation — Beyond encod- 
ings and primitives, there must be a common model of node 
resources and the means by which policies governing their 
allocation are communicated. The resources to be modeled 
include physical resources, such as transmission bandwidth, 
processing capacity, and storage, as well as logical resources, 
such as routing tables and the node's management informa- 
tion base. Safe resource allocation is an area that will require 
considerable attention. Active nodes will be embedded within 
the shared network infrastructure, so their designs must 
address a range of sharing issues that are often brushed aside 
in the design of programmable systems destined for less pub- 
lic environments. 

Current Research 

iy|/ork on active networks is underway at a number of 
W sites which are independently studying: capsule and 
programmable switch architectures; enabling technologies; 
specification techniques; end system issues; and applica- 
tions, including network, mobility, and congestion man- 
agement. 

Massachusetts Institute of Technology 

The MIT team is prototyping an architecture based on the 
capsule approach [17] and studying issues related to compo- 




nent specification, "active storage," 
multicast negative acknowledgment 
(NACK) fusion, and network-based 
traffic filtering. A reference plat- 
form that demonstrates the capsule 
architecture is being implemented 
on Linux using Java-based capsule 
encoding. Additional enabling tech- 
nologies, including advanced operating system techniques [14] 
and "on-the-fly w compilation [16], are also under investiga- 
tion. 

Capsules use the built-in constructs of a programming lan- 
guage to perform packet processing. This language will be 
extended through the specification of a suite of "foundation 
components" that invoke built-in primitives and interact with 
the local node environment, and can be extended and special- 
ized to suit application-specific requirements. Demand load- 
ing and the caching of components are being developed as 
strategies to support compact programs and reduce the over- 
bead associated with their transfer and evaluation. Demand 
loading allows capsules to reference components rather than 
carry them; and caching implies that recently used compo- 
nents need not be reloaded and verified for safety. 

Programming will also be facilitated by allowing capsules 
to leave "soft state" behind in a node. Thus, a flow or connection 
may be opened by having a capsule leave a small amount of 
associated state at each node along the path it traverses. Subr 
sequent packets can include code whose execution leverages 
this "soft state" but can regenerate it if necessary. Connec- 
tions and flows in active networks can be more powerful than 
those of present-day systems because the state left behind may 
be in the form of programs. A more persistent form of active 
storage, workflow state, is being developed to support loosely 
synchronized activities and track dependencies. 

University of Pennsylvania 
The SwitchWare project [18] is developing a programmable 
switch approach that allows digitally signed type-checked 
modules to be loaded into the nodes of a network. The basic 
idea is to raise the level of abstraction of the switch function- 
ality closer to that of a Turing machine. Aspects of security 
dictate limitations in the trade-offs which can be made in sup 
port of other goals: resource allocation must be robust enough 
that denial of service attacks are frustrated; extensibility must 
be restricted to preclude security breaches, yet still adequate 
for advanced applications. 

Perm's approach uses formal methodologies to prove secu- 
rity properties of SwitchWare programs. The focus of Switch- 
Ware is the identification of properties of the underlying 
infrastructure for which theorems can be developed. Proofs 
are supported by a language (SML/NJ) with a precise defini- 
tion and runtime support that includes concurrent garbage 
collection and resource allocation. An advantage of support- 
ing security at the programming language level is that the high 
overhead of protection domain-crossing in kernelized operat- 
ing systems is avoided, since the need for carefully gated entry 
points is removed at compilation time. 

The approach will be evaluated with a prototype based on 
a shared-memory multiprocessor. Early prototype applications 
include software-scalable bandwidth based on a general 
mechanism for inverse multiplexing (i.e., network striping) 
and support for an active packet model ("Switchlets^. 

Beul Communications Research 
Several aspects of the Penn design will be studied jointly with 
Bellcore, using a different infrastructure (OPCV2) to extend 
the design space explored. The output port controller version 
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2 (0PCV2) attaches to the Sun- 
shine asynchronous transfer mode 
(ATM) switch, developed for the 
AURORA gigabit testbed, and can 
also be used as a standalone pro- 
cessor that enables line speed 
manipulation of ATM streams. This 
allows studies of SwitchWare multi- 
plexing algorithms and run-time 
system functionality to be embed- 
ded in the port controllers of a scal- 
able switch. ^Mmmmtmm^^mt 

A second component of the Bell- 
core effort is the specification of the semantics of an active 
router, and the investigation of those semantics in a collabora- 
tive prototyping effort involving Penn. The prototype will use 
a small-scale multiprocessor as an active network element that 
interconnects ATM networks with 10 and 100 Mb/s Ethernets. 
This active router will serve as an experimental platform for 
the investigation of applications under development within the 
SwitchWare project. 

Bellcore is also studying uses of the new network infra- 
structure, such as self-paying information transport, in 
which electronic payment information is embedded in the 
active packets. Bellcore's interest in active networks is relat- 
ed to its previous work on protocol boosters [19], which 
dynamically optimize protocol components on an end-to- 
end basis, and the advanced intelligent network (AIN), 
which separated the implementation of value added services 
from switching, by moving the service control functions to 
adjunct processors. 

Columbia university 

The NetScript project, led by Yemini and da Silva [20], con- 
sists of a programming language and execution environment. 
The language provides a means to script the processing of 
packet streams. It is particularly suited to the implementation 
of routing, packet analysis, signaling, and management func- 
tions. NetScript agents can be sent to remote systems includ- 
ing intermediate network nodes, such as routers and switches. 
The goal is to enable programming of these nodes as easily 
and quickly as end systems. 

Carnegie Mellon University 

The CMU team, led by Steenkiste and Zhang, is developing 
resource management mechanisms in support of "application- 
aware" networks. They are considering three dimensions of 
resource allocation: physical infrastructure, including process- 
ing and storage; decision making on different time scales, 
ranging from application startup to packet and cell schedul- 
ing; and the sharing of infrastructure among organizational 
entities. The mechanisms will support network customization 
across all three dimensions. 

CMU is also exploring support for sophisticated multiparty 
applications, such as video conferencing and data mining, that 
use multiple traffic streams with divergent characteristics. 
These applications will be "network-aware" so that they can 
perform well on a variety of networks and adapt quickly to 
changing network conditions. 

Work Elsewhere 

Additional research on active networks is being conducted at 
several sites: 

• At BBN, Partridge and Jackson are exploring issues of 
programmability, data dictionaries, and authentication 
mechanisms, in the context of IP and to improve man- 
agement and diagnostic capabilities. 



^^^^ 




•At the Georgia Institute of 
Technology, active network 
concepts are being applied to 
network congestion by allow- 
ing applications to request 
that specific node algorithms 
(e.g., lossless compression, 
selective discard, and 
transcoding) be invoked dur- 
ing periods of congestion [21]. 
•At the University of Kansas, 
HMMMM^Mn K 'W r : Frost and Minden are consid- 
ering the application of active 
technologies to rapidly deployable ratio networks. 

• At the University of Arizona, Peterson is developing "liq- 
uid" software, a suite of mobile code technologies that 
includes rapid compilation of intermediate code (i.e., at 
network link rates) [22]. 

• At the University of Cincinnati, Alexander is investigating 
techniques for the formal specification of network ele- 
ments and behavior. 

Summary 

M/ e realize th at suggestions for software-intensive approaches 
If If to networking surface every ten years or so. For exam- 
ple, Zander [23] describes an experimental system in which 
packets of FORTH code were interpreted by network elements. 
Nonetheless, we are convinced that recent improvements in 
the safety and efficiency of active technologies, and the 
demand created by lead applications, present new research 
opportunities. 

Active networks involve the synthesis and extension of 
programming language, operating systems, and networking 
expertise. We also anticipate changes to the organization of 
end system software — in place of protocol "stacks," appli- 
cations may use protocol "components" that can be special- 
ized and composed to perform application-specific 
functions [24]. This will lead to a massive increase in the 
degree and sophistication of network-based computation 
and address the mismatch between the rate at which user 
requirements change and the pace at which network infra- 
structure can be deployed. 
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Active Networks 

Mission 

Networks that "turn on a dime." 



ACTIVE NETWORKS 




• Network is rigid 
relatively passive 



Vision 

The Active Networks program has the goal of producing a new 
networking platform, flexible and extensible at runtime to accommodate 
the rapid evolution and deployment of networking technologies and also 
to provide the increasingly sophisticated services demanded by defense 
applications. 

The Active Nets architecture is based on a highly dynamic runtime 
environment that supports a finely tuned degree of control over network 
services. The packet itself is the basis for describing, provisioning, or 
tailoring resources to achieve the delivery and management 
requirements. A possible architecture utilizes a " Smart Packet " for the 
basic message unit on the Active Network; such a packet is an agent 
with the goal of delivering itself to its destination. The goal is expressed 
through a portion of the packet that describes its "method" - a set of 
instructions that can be interpreted consistently by the Active Network 
nodes. The entire ensemble will be engineered to allow security, 
reliability, availability and quality of service to be tuned at multiple levels 
of granularity and under a wide range of conditions. 

The evolution of defense networks by the injection of newly designed 



http://www.Jaipa.mil/ato/programs/activenetworks/actnet.htm 



7/16/2004 



Active Networks 



Page 2 of 3 



services is needed in order to deploy new strategies or to tailor the 
infrastructure to immediate needs. The Active Network architecture 
supports this malleability as a first-class design goal, one that will 
reduce the time and cost of deploying new services. An additional 
dimension to network evolution will be the ability to support a multiplicity 
of network behaviors to be supported through the "virtualization" of the 
underlying infrastructure. Other crucial research topics include routing, 
resource allocation and network management services built with active 
network concepts. 

There are crucial application areas that can benefit from the flexibility of 
the Active Network architecture, and breakthrough approaches will be 
sought. Areas of likely specialization include flexible, efficient, and 
secure protocols for: group communication strategies, scalable network 
management, quality of service management techniques, and radically 
more efficient routing protocols. 

Goals 

• Quantifiable Improvement in Network Services 

• Audio/video synchronization and full-rate video over multicast 

• Fewer retransmitted packets, 100% increase in useful data rate to 
end applications 

• Architecture Creates Solutions to Future DoD Needs 

• e.g., "addressless" networks, resource directed communication 

• Fault-Tolerance Mechanisms Based in Network 

• Multi-Tiered Mobile Security 

• Authentication forms basis for dynamic access control 

• Separate traffic and administrative functions based on types and 
policy 

Challenges 

Composite Protocols 

• SmartPacket processing must be efficient, secure and survivable 
Enhanced Network Services 

• Quickly and safely deploy new services 

• Achieve widespread use without need for standardization process 

• Upgrade crucial network services to keep pace with network 
complexity (size, speed, variety) 

• Develop new strategies for routing and service provisioning in 
large networks that have overlapping topologies and mobility 
requirements 
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Active Networks - Smart Packets 

Static Packets: Network elements constrained to simple functions 
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